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ABSTRACT 



A system for controlling the distribution and use of digital 
works using digital tickets. In the present invention, a 
"digital ticket" is used to entitle the ticket holder to exercise 
some usage right with respect to a digital work. Usage rights 
are used to define how a digital work may be used or 
distributed. Each usage right may specify a digital ticket 
which must be present before the right may be exercised. 
Digital works are stored in repositories which enforce a 
digital works usage rights. Each repository has a "generic 
ticket agent" which punches tickets. In some instances only 
the generic ticket agent is necessary. In other instances, 
punching by a "special ticket agent" residing on another 
repository may be needed. 

9 Claims, 13 Drawing Sheets 
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1501^ Digital Work Rights:= (Rights*) 

1502 — Right : = (Right-Code {Copy-Count} {Control-Spec} {Time-Spec } 
{Access-Spec} {Fee-Spec}) 
1503 — Right-Code : = Render-Code | Transport-Code | FUe-Management- 
Code| Derivative-Works- Code | Configuration-Code 
f 504~Render-Code : = [ Play : {Player: Player-ID} | Print: {Printer. Printer-ID}] 
1505' — -Transport-Code : = [Copy | Transfer | Loan {Remaining-Rights: 

Next-Set-of-mghts}H(NextCopy-Rights:Next5e1x>f-Rights)} 
1506 — File-Management-Code := Backup {Back-Up-Copy-Rights: 

Next-Set-of-Rights} | Restore | Delete | Folder 
| Directory {Name: Hide-Local | Hide-Remote} 
{Parts: Hide-Local | Hide-Remote} 
1 507^— Derivative-Workfl-Code : = [Extract | Embed | Edit{Process: 

Process-ID}] {Next-Copy-Rights : 
Next-Set-of Rights} 
1 503— Configuration-Code : = Install | Uninstall 
1509 — Next*Set-of-Rights := {(Add: Set-Of-Rights)} {(Delete: 

Set-Of-Rights)} {(Replace: Set-Of-Rights >H(Keep: Set-Of-Rights )} 
151 0~*-Copy-Count := (Copies:positive-integer 1 0 1 Unlimited) 
1511^ Control-Spec := (Control: {Restrictable | Unrestrictable} 

{Unchargeable | Chargeable}) 
f572~Time-Spec := ({Fixed-Interval | SHding-Interval | Meter-Time} 
Until: Expiration-Date) 
1 513 ~ fixed-Interval := From: Start-Time 

1 51 4 — - Sliding-Inte rval : = Interval: Use-Duration 

1515 — 'Meter-Time: = Time-Remaining: Remaining-Use 

I5J6"~— Access-Spec := ({SC: Security-Class} {Authorization: Authorization-ID*} 

{Other-Authorization: Authorization-ID*} {Ticket: Ticket-ID}) 
151 7— Fee-Spec: = {Scheduled-Discount} Regular-Fee-Spec | Scheduled-Fee-Spec | 
Markup-Spec 

?5ffl~Scheduled-Discount: = Scheduled-Discount: (Scheduled-Discount: 

(Time-Spec Percentage)*) 

1519~-~ Regular-Fee-Spec := ({Fee: (Incentive:} [Per-Use-Spec | Metered-Rate- 

Spec | Best-Price-Spec | Call-For-Price-Spec] 
{Min: Money-Unit Per Time-Spec}{Max: 
Money-Unit Per: Time-Spec} To: Account-ID) 

1520 — Per-Use-Spec: - Per-Use: Money-unit 

1521 — Metered-Rate-Spec := Metered: Money-Unit Pen Time-Spec 
f 522— Best-Price-Spec := Best-Price: Money-unit Max: Money-unit 
1523 — Call-For-Price-Spec := Call-For -Price 

1 524 — ■ Scheduled-Fee-Spec: = (Schedule: (Time-Spec Regular-Fee-Spec)* ) 

1 525 — -Markup-Spec: = Markup: percentage To: Account-ID 

Fig.15 
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SYSTEM FOR CONTROLLING THE 
DISTRIBUTION AND USE OF DIGITAL 
WORKS USING DIGITAL TICKETS 

RELATED APPLICATIONS 

This application is a continuation of application Ser. No. 
08/344,760, filed Nov. 23, 1994, now abandoned. 

This application is related to the following and commonly 
assigned patent applications: 

Ser. No. 08/344,041, entitled "System For Controlling 
The Distribution And Use Of Digital Works Having 
Attached Usage Rights Where The Usage Rights Are 
Defined By A Usage Rights Grammar" filed Nov. 23, 1994 
now U.S. Pat. No. 5,715,403; 

Ser. No. 08/344,773, entitled "System For Controlling 
The Distribution And Use Of Digital Works Having A Fee 
Reporting Mechanism" filed Nov. 23, 1994 now U.S. Pat. 
No. 5,634,012; 

Ser. No. 08/344,042, entitled "System For Controlling the 
Distribution and Use Of Digital Works" filed Nov. 23, 1994 
now U.S. Pat. No. 5,629,980; and 

Ser. No. 08/344,776, entitled "System For Controlling the 
Distribution and Use of Composite Digital Works" filed 
Nov. 23, 1994 now U.S. Pat. No. 5,638,443. 

FIELD OF THE INVENTION 

The present invention relates to the field of distribution 
and usage rights enforcement for digitally encoded works. 

BACKGROUND OF THE INVENTION 

A fundamental issue facing the publishing and informa- 
tion industries as they consider electronic publishing is how 
to prevent the unauthorized and unaccounted distribution or 
usage of electronically published materials. Electronically 
published materials are typically distributed in a digital form 
and recreated on a computer based system having the 
capability to recreate the materials. Audio and video 
recordings, software, books and multimedia works are all 
being electronically published. Companies in these indus- 
tries receive royalties for each accounted for delivery of the 
materials, e.g. the sale of an audio CD at a retail outlet. Any 
unaccounted distribution of a work results in an unpaid 
royalty (e.g. copying the audio recording CD to another 
digital medium.) 

The ease in which electronically published works can be 
"perfectly" reproduced and distributed is a major concern. 
The transmission of digital works over networks is com- 
monplace. One such widely used network is the Internet. 
The Internet is a widespread network facility by which 
computer users in many universities, corporations and gov- 
ernment entities communicate and trade ideas and informa- 
tion. Computer bulletin boards found on the Internet and 
commercial networks such as CompuServ and Prodigy 
allow for the posting and retrieving of digital information. 
Information services such as Dialog and LEXIS/NEX1S 
provide databases of current information on a wide variety 
of topics. Another factor which will exacerbate the situation 
is the development and expansion of the National Informa- 
tion Infrastructure (the Nil). It is anticipated that, as the Nil 
grows, the transmission of digital works over networks will 
increase many times over. It would be desirable to utilize the 
Nil for distribution of digital works without the fear of 
widespread unauthorized copying. 

The most straightforward way to curb unaccounted dis- 
tribution is to prevent unauthorized copying and transmis- 
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sion. For existing materials that are distributed in digital 
form, various safeguards are used. In the case of software, 
copy protection schemes which limit the number of copies 
that can be made or which corrupt the output when copying 
is detected have been employed. Another scheme causes 
software to become disabled after a predetermined period of 
time has lapsed. A technique used for workstation based 
software is to require that a special hardware device must be 
present on the workstation in order for the software to run, 

( e.g., see U.S. Pat. No. 4,932,054 entitled "Method and 
Apparatus for Protecting Computer Software Utilizing 
Coded Filter Network in Conjunction with an Active Coded 
Hardware Device." Such devices are provided with the 
software and are commonly referred to as dongles. 

Yet another scheme is to distribute software, but which 
requires a "key" to enable it's use. This is employed in 
distribution schemes where "demos" of the software are 
provided on a medium along with the eDtire product. The 
demos can be freely used, but in order to use the actual 

, product, the key must be purchased. These scheme do not 
hinder copying of the software once the key is initially 
purchased. 

A system for ensuring that licenses are in place for using 
licensed products is described in PCT Publication WO 
93/01550 to Griswold entitled "License Management Sys- 
tem and Method." The licensed product may be any elec- 
tronically published work but is most effective for use with 
works that are used for extended periods of time such as 
software programs. Griswold requires that the licensed prod- 
uct contain software to invoke a license check monitor at 
predetermined time intervals. The license check monitor 
generates request datagrams which identify the licensee. The 
request datagrams are sent to a license control system over 
an appropriate communication facility. The license control 
system then checks the datagram to determine if the data- 
gram is from a valid licensee. The license control system 
then sends a reply datagram to the license check monitor 
indicating denial or approval of usage. The license control 
system will deny usage in the event that request datagrams 
go unanswered after a predetermined period of time (which 
may indicate an unauthorized attempt to use the licensed 
product). In this system, usage is managed at a central 
location by the response datagrams. So for example if 
license fees have not been paid, access to the licensed 
product is terminated. 

It is argued by Griswold that the described system is 
advantageous because it can be implemented entirely in 
software. However, the system described by Griswold has 
limitations. An important limitation is that during the use of 
the licensed product, the user must always be coupled to an 
appropriate communication facility in order to send and 
receive datagrams. This creates a dependency on the com- 
munication facility. So if the communication facility is not 
available, the licensed product cannot be used. Moreover, 
some party must absorb the cost of communicating with the 
license server. 

A system for controlling the distribution of digitally 
encoded books is embodied in a system available from VPR 
Systems, LTD. of St. Louis, Mo. The VPR system is 
self-contained and is comprised of: (1) point of sale kiosks 
for storing and downloading of books, (2) personal storage 
mediums (cartridges) to which the books are downloaded, 
and (3) readers for viewing the book. In a purchase 
transaction, a purchaser will purchase a voucher card rep- 
resenting the desired book. The voucher will contain suffi- 
cient information to identify the book purchased and perhaps 
some demographic information relating to the sales trans- 
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action. To download the book, the voucher and the cartridge 
are inserted into the kiosk. 

The VPR system may also be used as a library. In such an 
embodiment, the kiosk manages the number of "copies" that 
may be checked out at one time. Further, the copy of the 
book is erased from the users cartridge after a certain 
check-out time has expired. However, individuals cannot 
loan books because the cartridges may only be used with th e 
owners reader. 



words, the means for billing runs with the media rather than 
the underlying work. It would be desirable to have a 
distribution system where the means for billing is always 
transported with the work. 

SUMMARY OF THE INVENTION 

A system for controlling the distribution and use of digital 
works using digital tickets is disclosed. A ticket is an 
indicator that the ticket holder has already paid for or is 
^ The foregoing distribution and protection schemes oper- 10 otherwise entitled to some specified right, product or ser- 
ate in part by preventing subsequent distribution of the work. vice - In ^ P resem invention, a "digital ticket" is used to 
While this certainly prevents unauthorized distributions, it enabIe me ucket nolder to exercise usage rights specifying 
does so by sacrificing the potential for subsequent revenue lhe requirement of the digital ticket. Usage rights are used to 
bearing uses. For example, it may be desirable to allow the dcfinc how a di 8 ital work ma y be 0T distributed, 
lending of a purchased work to permit exposure of the work 35 Specific instances of usage rights are used to indicate a 
to potential buyers. Another example would be to permit the particular manner of use or distribution. A usage right may 
creation of a derivative work for a fee. Yet another example s P eci fy a Ucket which must te P resent beforc the ri g ht 
would be to permit copying the work for a fee (essentially ma y exercised. For example, a digital ticket may be 
purchasing it). Thus, it would be desirable to provide flex- specified in a Copy right of a digital work, so that exercise 
ibility in how the owner of a digital work may allow it to be 20 of lhe ^Py ri g ht requires the party that desires a copy of the 



distributed. 

While flexibility in distribution is a concern, the owners 
of a work want to make sure they are paid for such 
distributions. In U.S. Pat. No. 4,977,594 to Shear, entitled 



digital work be in possession of the necessary digital ticket. 
After a copy of the digital work is successfully sent to the 
requesting party, the digital ticket is "punched" to indicate 
that a copy of the digital work has been made. When the 



"Database Usage Metering and Protection System and 25 ticl f * "P" nch ed" a predetermined number of times, it may 



Method," a system for metering and billing for usage of 
information distributed on a CD-ROM is described. The 
system requires the addition of a billing module to the 
computer system. The billing module may operate in a 
number of different ways. First, it may periodically com- 
municate billing data to a central billing facility, whereupon 
the user may be billed. Second, billing may occur by 
disconnecting the billing module and the user sending it to 
a central billing facility where the data is read and a user bill 
generated. 

U.S. Pat. No. 5,247,575, Sprague et aL, entitled "Infor- 
mation Distribution System", describes an information dis- 
tribution system which provides and charges only for user 
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no longer be used. 

Digital works are stored in repositories. Repositories 
enforce the usage rights for digital works. Each repository 
has a "generic ticket agent" which punches tickets. In some 
instances only the generic ticket agent is necessary. In other 
instances, punching by a "special ticket agent" residing on 
another repository may be desired. Punching by a "special 
ticket agent" enables greater security and control of the 
digital work. For example, it can help prevent digital ticket 
forgery. Special ticket agents are also useful in situations 
where an external database needs to be updated or checked. 

A digital ticket is merely an instance of a digital work. 
Thus, a digital ticket may be distributed among repositories 



selected information. A plurality of encrypted information 40 me fasbion & other digital works. 



packages (IPs) arc provided at the user site, via high and/or 
low density storage media and/or by broadcast transmission. 
Some of the IPs may be of no interest to the user. The IPs 
of interest are selected by the user and are decrypted and 
stored locally. The IPs may be printed, displayed or even 
copied to other storage medias. The charges for the selected 
IP's are accumulated within a user apparatus and periodi- 
cally reported by telephone to a central accounting facility. 
The central accounting facility also issues keys to decrypt 
the IPs. The keys are changed periodically. If the central 
accounting facility has not issued a new key for a particular 
user station, the station is unable to retrieve information 
from the system when the key is changed. 

A system available from Wave Systems Corp. of 
Princeton, N.Y., provides for metering of software usage on 
a personal computer. The system is installed onto a computer 
and collects information on what software is in use, encrypts 
it and then transmits the information to a transaction center. 
From the transaction center, a bill is generated and sent to 
the user. The transaction center also maintains customer 
accounts so that licensing fees may be forwarded directly to 
the software providers. Software operating under this system 
must be modified so that usage can be accounted. 

Known techniques for billing do not provide for billing of 
copies made of the work. For example, if data is copied from 
the CD-ROM described in Shear, any subsequent use of the 
copy of the information cannot be metered or billed. In other 
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A digital ticket may be used in many commercial sce- 
narios such as in the purchase of software and prepaid 
upgrades. A digital ticket may also be used to limit the 
number of times that a right may be exercised. For example, 
a user may purchase a copy of a digital work, along with the 
right to make up to 5 Copies. In this case, the Copy right 
would have associated therewith a digital ticket that can be 
punched up to 5 times. Other such commercial scenarios will 
become apparent from the detailed description. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a flowchart illustrating a simple instantiation of 
the operation of the currently preferred embodiment of the 
present invention. 

FIG. 2 is a block diagram illustrating the various reposi- 
tory types and the repository transaction flow between them 
in the currently preferred embodiment of the present inven- 
tion. 

FIG. 3 is a block diagram of a repository coupled with a 
credit server in the currently preferred embodiment of the 
present invention. 

FIGS. 4a and 4b are examples of rendering systems as 
may be utilized in the currently preferred embodiment of the 
present invention. 

FIG. 5 illustrates a contents file layout for a digital work 
as may be utilized in the currently preferred embodiment of 
the present invention. 
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FIG. 6 illustrates a contents file layout for an individual 
digital work of the digital work of FIG. 5 as may be utilized 
in the currently preferred embodiment of the present inven- 
tion. 

FIG. 7 illustrates the components of a description block of 
the currently preferred embodiment of the present invention. 

FIG. 8 illustrates a description tree for the contents file 
layout of the digital work illustrated in FIG. 5. 

FIG. 9 illustrates a portion of a description tree corre- 
sponding to the individual digital work illustrated in FIG. 6. 

FIG. 10 illustrates a layout for the rights portion of a 
description block as may be utilized in the currently pre- 
ferred embodiment of the present invention. 

FIG. 11 is a description tree wherein certain d-b locks have 
PRINT usage rights and is used to illustrate "strict" and 
"lenient" rules for resolving usage rights conflicts. 

FIG. 12 is a block diagram of the hardware components 
of a repository as are utilized in the currently preferred 
embodiment of the present invention. 

FIG. 13 is a block diagram of the functional (logical) 
components of a repository as are utilized in the currently 
preferred embodiment of the present invention. 

FIG. 14 is diagram illustrating the basic components of a 
usage right in the currently preferred embodiment of the 
present invention. 

FIG. 15 lists the usage rights grammar of the currently 
preferred embodiment of the present invention. 

FIG. 16 is a flowchart illustrating the steps of certificate 
delivery, hotlist checking and performance testing as per- 
formed in a registration transaction as may be performed in 
the currently preferred embodiment of the present invention. 

FIG. 17 is a flowchart illustrating the steps of session 
information exchange and clock synchronization as may be 
performed in the currently preferred embodiment of the 
present invention, after each repository in the registration 
transaction has successfully completed the steps described in 
FIG. 16. 
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FIG. 18 is a flowchart illustrating the basic flow for a 40 alterati ° n » reuse and billin S-. 



Usage Fees and Incentives Specification 

Examples of Sets of Usage Rights 
REPOSITORY TRN AS ACTIONS 

Message Transmission 

Session Initiation Transactions 

Billing Transactions 

Usage Transacitons 

Transmission Protocol 

The Copy Transaction 

The Transfer Transaction 

The Loan Transaction 

The Play Transaction 

The Print Transaction 

The Backup Transaction 

The Restore Transaction 

The Delete Transaction 

The Folder Transaction 

The Extract Transaction 

The Edit Tranaction 

The Authorization Transaction 

The Install Transaction 

The Uninstall Transaction 
DISTRIBUTION AND USE SCENARIOS 
GLOSSARY 
Overview 

A system for controlling use and distribution of digital 
works is disclosed. The present invention is directed to 
supporting commercial transactions involving digital works. 
The transition to digital works profoundly and fundamen- 
tally changes how creativity and commerce can work. It 
changes the cost of transporting or storing works because 
digital property is almost "massless." Digital property can 
be transported at electronic speeds and requires almost no 
warehousing. Keeping an unlimited supply of virtual copies 
on hand requires essentially no more space than keeping one 
copy on hand. The digital medium also lowers the costs of 



There is a market for digital works because creators are 
strongly motivated to reuse portions of digital works from 
others rather than creating their own completely. This is 

ct^ in- ..j- c ji-. because it is usually so much easier to use an existing stock 

FIG. 19 is a state diagram of server and client repositories jeU . • r \u * ♦ * u 

a ™^n~> „-th , .™™, t 1 fcnJL 45 P hoto or music cb P man 10 CTeate a ncw ooe torn scratch. 

Herein the terms "digital work", "work" and "content" 



usage transaction, including the common opening and clos- 
ing step, as may be performed in the currently preferred 
embodiment of the present invention. 



in accordance with a transport protocol followed when 
moving a digital work from the server to the client 
repositories, as may be performed in the currently preferred 
embodiment of the present invention. 

DETAILED DESCRIPTION OF THE 50 
PREFERRED EMBODIMENT 

TABLE OF CONTENTS 

OVERVIEW 

RENDERING SYSTEMS 55 

STRUCTURE OF DIGITAL WORKS 

ATTACHING USAGE RIGHTS TO A DIGITAL WORK 

Resolving Conflicitng Rights 
REPOSITORIES 

Repository Security Classes eo 

Repository User Interface 
CREDLT SERVICES 
USAGE RIGHTS LANGUAGE 

Copy Count Specification 

Control Specification 65 
Time Specification 

Security Class and Authorization Specification 



refer to any work that has been reduced to a digital repre- 
sentation. This would include any audio, video, text, or 
multimedia work and any accompanying interpreter (e.g. 
software) that may be required for recreating the work. The 
term composite work refers to a digital work comprised of 
a collection of other digital works. The term "usage rights" 
or "rights" is a term which refers to rights granted to a 
recipient of a digital work. Generally, these rights define 
how a digital work can be used and if it can be further 
distributed. Each usage right may have one or more specified 
conditions which must be satisfied before the right may be 
exercised. A Glossary of the terms used herein is provided 
at the end of the specification. 

A key feature of the present invention is that usage rights 
are permanently "attached" to the digital work. Copies made 
of a digital work will also have usage rights attached. Thus, 
the usage rights and any associated fees assigned by a 
creator and subsequent distributor will always remain with 
a digital work. 

The enforcement elements of the present invention are 
embodied in repositories. Among other things, repositories 
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are used to store digital works, control access to digital requiring an authorization. Conceptually, an authorization is 

works, bill for access to digital works and maintain the a digital certificate such that possession of the certificate is 

security and integrity of the system. required to gain access to the digital work. An authorization 

The combination of attached usage rights and repositories is itself a digital work that can be moved between reposi- 

enable distinct advantages over prior systems. As noted in 5 tones and subjected to fees and usage rights conditions. An 

the prior art, payment of fees are primarily for the initial authorization may be required by both repositories involved 

access. In such approaches, once a work has been read, m m access t0 a digita i WOfk 

computational control over that copy is gone. Communication with a rendering repository 203 occurs in 

Metaphorically the content genie is out of the bottle and no connection ^ ^ renderin of f ^ M ^ be 

more fees can be billed." In contrast, the present invention , . . .j.-iui j ■ 

never separates the fee descriptions from the work. Thus, the 10 desa * cd 10 J*™ 161 ? clow > 5 renderm & re P° sltor y 15 

digital work genie only moves from one trusted bottle Wlth a «ndermg device (e.g. a prmter device) to 

(repository) to another, and all uses of copies are potentially comprise a rendering system. 

controlled and billable. Communication with a master repository 205 occurs in 

FIG. 1 is a high level flowchart omitting various details connection with obtaining an identification certificate. Iden- 

but which demonstrates the basic operation of the present 15 location certificates are the means by which a repository is 

invention. Referring to FIG. 1, a creator creates a digital identified as "trustworthy". The use of identification certifi- 

work, step 101. The creator will then determine appropriate cates is described below with respect to the registration 

usage rights and fees, attach them to the digital work, and transaction. 

store them in Repository 1, step 102. The determination of FIG. 3 illustrates the repository 201 coupled to a credit 
appropriate usage rights and fees will depend on various 20 server 301. The credit server 301 is a device which accu- 
economic factors. The digital work remains securely in mulates billing information for the repository 201. The 
Repository 1 until a request for access is received. The credit server 301 communicates with repository 201 via 
request for access begins with a session initiation by another billing transactions 302 to record billing transactions. Bill- 
repository. Here a Repository 2 initiates a session with ing transactions are reported to a billing clearinghouse 303 
Repository 1, step 103. As will be described in greater detail 25 by the credit server 301 on a periodic basis. The credit server 
below, this session initiation includes steps which helps to 301 communicates to the billing clearinghouse 303 via 
insure that the respective repositories are trustworthy. clearinghouse transactions 304. The clearinghouse transac- 
Assuming that a session can be established, Repository 2 tions 304 enable a secure and encrypted transmission of 
may then request access to the Digital Work for a stated information to the billing clearinghouse 303. 
purpose, step 104. The purpose may be, for example, to print 30 Rendering Systems 

the digital work or to obtain a copy of the digital work. The A rendering system is generally defined as a system 
purpose will correspond to a specific usage right. In any comprising a repository and a rendering device which can 
event, Repository 1 checks the usage rights associated with render a digital work into its desired form. Examples of a 
the digital work to determine if the access to the digital work rendering system may be a computer system, a digital audio 
may be granted, step 105. The check of the usage rights 35 system, or a printer. A rendering system has the same 
essentially involves a determination of whether a right security features as a repository. The coupling of a rendering 
associated with the access request has been attached to the repository with the rendering device may occur in a manner 
digital work and if all conditions associated with the right suitable for the type of rendering device, 
are satisfied. If the access is denied, repository 1 terminates FIG. 4a illustrates a printer as an example of a rendering 
the session with an error message, step 106. If access is 40 system. Referring to FIG. 4, printer system 401 has con- 
granted, repository 1 transmits the digital work to repository tained therein a printer repository 402 and a print device 
2, step 107. Once the digital work has been transmitted to 403. It should be noted that the dashed line defining printer 
repository 2, repository 1 and 2 each generate billing infor- system 401 defines a secure system boundary. Communica- 
mation for the access which is transmitted to a credit server, tions within the boundary is assumed to be secure. Depend- 
step 108. Such double billing reporting is done to insure 45 ing on the security level, the boundary also represents a 
against attempts to circumvent the billing process. barrier intended to provide physical integrity. The printer 
FIG. 2 illustrates the basic interactions between repository repository 402 is an instantiation of the rendering repository 
types in the present invention. As will become apparent from 205 of FIG. 2. The printer repository 402 will in some 
FIG. 2, the various repository types will serve different instances contain an ephemeral copy of a digital work which 
functions. It is fundamental that repositories will share a so remains until it is printed out by the print engine 403. In 
core set of functionality which will enable secure and trusted other instances, the printer repository 402 may contain 
communications. Referring to FIG. 2, a repository 201 digital works such as fonts, which will remain and can be 
represents the general instance of a repository. The reposi- billed based on use. This design assures that all communi- 
tory 201 has two modes of operation; a server mode and a cation lines between printers and printing devices are 
requester mode. When in the server mode, the repository 55 encrypted, unless they are within a physically secure bound- 
will be receiving and processing access requests to digital ary. This design feature eliminates a potential "fault" point 
works. When in the requester mode, the repository will be through which the digital work could be improperly 
initiating requests to access digital works. Repository 201 is obtained. The printer device 403 represents the printer 
general in the sense that it's primary purpose is as an components used to create the printed output, 
exchange medium for digital works. During the course of 60 Also illustrated in FIG. 4a is the repository 404. The 
operation, the repository 201 may communicate with a repository 404 is coupled to the printer repository 402. The 
plurality of other repositories, namely authorization reposi- repository 404 represents an external repository which con- 
tory 202, rendering repository 203 and master repository tains digital works. 

204. Communication between repositories occurs utilizing a FIG. 4b is an example of a computer system as a rendering 
repository transaction protocol 205. 65 system. A computer system may constitute a "multi- 
Communication with an authorization repository 202 may function" device since it may execute digital works (e.g. 
occur when a digital work being accessed has a condition software programs) and display digital works (e.g. a digi- 
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lized photograph). Logically, each rendering device can be 
viewed as having it's own repository, although only one 
physical repository is needed. Referring to FIG. 4b, a 
computer system 410 has contained therein a display/ 
execution repository 411. The display/execution repository 
411 is coupled to display device, 412 and execution device 
413. The dashed box surrounding the computer system 410 
represents a security boundary within which communica- 
tions are assumed to be secure. The display/execution 
repository 411 is further coupled to a credit server 414 to 
report any fees to be billed for access to a digital work and 
a repository 415 for accessing digital works stored therein. 
Structure of Digital Works 

Usage rights are attached directly to digital works. Thus, 
it is important to understand the structure of a digital work. 
The structure of a digital work, in particular composite 
digital works, may be naturally organized into an acyclic 
structure such as a hierarchy. For example, a magazine has 
various articles and photographs which may have been 
created and are owned by different persons. Each of the 
articles and photographs may represent a node in a hierar- 
chical structure. Consequently, controls, i.e. usage rights, 
may be placed on each node by the creator. By enabling 
control and fee billing to be associated with each node, a 
creator of a work can be assured that the rights and fees are 
not circumvented. 

In the currently preferred embodiment, the file informa- 
tion for a digital work is divided into two files: a "contents" 
file and a "description tree" file. From the perspective of a 
repository, the "contents" file is a stream of addressable 
bytes whose format depends completely on the interpreter 
used to play, display or print the digital work. The descrip- 
tion tree file makes it possible to examine the rights and fees 
for a work without reference to the content of the digital 
work. It should be noted that the term description tree as 
used herein refers to any type of acyclic structure used to 
represent the relationship between the various components 
of a digital work. 

FIG. 5 illustrates the layout of a contents file. Referring to 
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embodiment, the identifier 701 has two parts. The first part 
is a unique number assigned to the repository upon manu- 
facture. The second part is a unique number assigned to the 
work upon creation. The rights portion 704 will contain a 
data structure, such as a look-up table, wherein the various 
information associated with a right is maintained. The 
information required by the respective usage rights is 
described in more detail below. D-blocks form a strict 
hierarchy. The top d -block of a work has no parent; all other 
d-blocks have one parent. The relationship of usage rights 
between parent and child d-blocks and how conflicts are 
resolved is described below. 

A special type of d-block is a "shell" d -block. A shell 
d-block adds no new content beyond the content of its parts. 
A shell d-block is used to add rights and fee information, 
typically by distributors of digital works. 

FIG. 8 illustrates a description tree for the digital work of 
FIG. 5. Referring to FIG. 8, a top d-block 820 for the digital 
work points to the various stories and advertisements con- 
tained therein. Here, the top d-block 820 points to d-block 
821 (representing story A 510), d-block 822 (representing 
the advertisement 511), d-block 823 (representing story B 
512) and and d-block 824 (representing story C 513). 

The portion of the description tree for Story A 510 is 
illustrated in FIG. 9. D-block 925 represents text 614, 
d-block 926 represents photo 615, d-block 927 represents 
graphics 616 by and d-block 928 represents sidebar 617. 

The rights portion 704 of a descriptor block is further 
illustrated in FIG. 10. FIG. 10 illustrates a structure which 
is repeated in the rights portion 704 for each right. Referring 
to FIG. 10, each right will have a right code field 1001 and 
status information field 1002. The right code field 1001 will 
contain a unique code assigned to a right. The status 
information field 1002 will contain information relating to 
the state of a right and the digital work. Such information is 
indicated below in Table 1. The rights as stored in the rights 
portion 304 may typically be in numerical order based on the 
right code. 

The approach for representing digital works by separating 



FIG. 5, a digital work 509 is comprised of story A 510, 40 description data from content assumes that parts of a file are 



advertisement 511, story B 512 and story C 513. It is 
assumed that the digital work is stored starting at a relative 
address of 0. Each of the parts of the digital work are stored 
linearly so that story A 510 is stored at approximately 
addresses 0-30,000, advertisement 511 at addresses 45 
30,001^tt),000, story B 512 at addresses 40,001-60,000 and 
story C 513 at addresses 60,001-85 K. The detail of story A 
510 is illustrated in FIG. 6. Referring to FIG. 6, the story A 
510 is further broken down to show text 614 stored at 
address 0-1500, soldier photo 615 at addresses 1501-10, 
000, graphics 616 stored at addresses 10,001-25,000 and 
sidebar 617 stored address 25,001-30,000, Note that the 
data in the contents file may be compressed (for saving 
storage) or encrypted (for security). 

From FIGS. 5 and 6 it is readily observed that a digital 
work can be represented by its component parts as a hier- 
archy. The description tree for a digital work is comprised of 
a set of related descriptor blocks (d-blocks). The contents of 
each d-block is described with respect to FIG. 7. Referring 
to FIG. 7, a d-block 700 includes an identifier 701 which is 
a unique identifier for the work in the repository, a starting 
address 702 providing the start address of the first byte of the 
work, a length 703 giving the number of bytes in the work, 
a rights portion 704 wherein the granted usage rights and 
their status data are maintained, a parent pointer 705 for 
pointing to a parent d-block and child pointers 706 for 
pointing to the child d-blocks. In the currently preferred 
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contiguous but takes no position on the actual representation 
of content. In particular, it is neutral to the question of 
whether content representation may take an object oriented 
approach. It would be natural to represent content as objects. 
In principle, it may be convenient to have content objects 
that include the billing structure and rights information that 
is represented in the d-blocks. Such variations in the design 
of the representation are possible and are 

TABLE 1 



Property 



PIGITAL WORK STATE INFORMATION 
Value Use 



Copies -in- 



Loan-Period 



Loaner-Copy 



Remaining- 

Time 
Document- 

Descr 



Number A counter of the number of copies of a 
work that are in use. Incremented when 
another copy is used; decremented when 
use is completed. 
Time-Units Indicator of the maximum number of 
time-units that a document can be 
loaned out 

Boolean Indicator that the current work is a 

loaned out copy of an authorized digital 
work. 

Time-Units Indicator of the remaining lime of use 
on a metered document right. 
String A string containing various identifying 
information about a document. The 
exact format of this is not specified, but 
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TABLE 1-continued 



12 



Property 



DIGITAL WORK STATE INFORMATION 
\alue Use 



it can include information such as a 

publisher name, author name, ISBN 

number, and so on. 
RO-Descr A handle identifying a revenue owner 

for a digital work. This is used for 

reporting usage fees. 
Date-Descr The date that the digital work was 

published. 

History- Rec A list of events recording the repositories 
and dates for operations that copy, 
transfer, backup, or restore a digital 
work. 



Revenue- 
Owner 

Publication- 
Date 
History-list 
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viable alternatives but may introduce processing overhead, 
e.g. the interpretation of the objects. 

Digital works are stored in a repository as part of a 
hierarchical file system. Folders (also termed directories and 
sub-directories) contain the digital works as well as other 
folders. Digital works and folders in a folder are ordered in 
alphabetical order. The digital works are typed to reflect how 
the files are used. Usage rights can be attached to folders so 
that the folder itself is treated as a digital work. Access to the 
folder would then be handled in the same fashion as any 
other digital work As will be described in more detail below, 
the contents of the folder are subject to their own rights. 
Moreover, file management rights may be attached to the 
folder which define how folder contents can be managed. 
Attaching Usage Rights to a Digital Work 

It is fundamental to the present invention that the usage 
rights are treated as part of the digital work. As the digital 
work is distributed, the scope of the granted usage rights will 
remain the same or may be narrowed. For example, when a 
digital work is transferred from a document server to a 
repository, the usage rights may include the right to loan a 
copy for a predetermined period of time (called the original 
rights). When the repository loans out a copy of the digital 
work, the usage rights in the loaner copy (called the next set 
of rights) could be set to prohibit any further rights to loan 
out the copy. The basic idea is that one cannot grant more 
rights than they have. 

The attachment of usage rights into a digital work may 
occur in a variety of ways. If the usage rights will be the 
same for an entire digital work, they could be attached when 
the digital work is processed for deposit in the digital work 
server. In the case of a digital work having different usage 
rights for the various components, this can be done as the 
digital work is being created. An authoring tool or digital 
work assembling tool could be utilized which provides for 
an automated process of attaching the usage rights. 

As will be described below, when a digital work is copied, 
transferred or loaned, a "next set of rights" can be specified. 
The"next set of rights" will be attached to the digital work 
as it is transported. 
Resolving Conflicting Rights 

Because each part of a digital work may have its own 
usage rights, there will be instances where the rights of a 
"contained part" are different from its parent or container 
part. As a result, conflict rules must be established to dictate 
when and how a right may be exercised. The hierarchical 
structure of a digital work facilitates the enforcement of such 
rules. A "strict" rule would be as follows: a right for a part 
in a digital work is sanctioned if and only if it is sanctioned 
for the part, for ancestor d-blocks containing the part and for 
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all descendent d-blocks. By sanctioned, it is meant that (1) 
each of the respective parts must have the right, and (2) any 
conditions for exercising the right are satisfied. 

It also possible to implement the present invention using 
a more lenient rule. In the more lenient rule, access to the 
part may be enabled to the descendent parts which have the 
right, but access is denied to the descendenls which do not. 

Example of applying both the strict rule and lenient is 
illustrated with reference to FIG. 11. Referring to FIG. 11, a 
root d-block 1101 has child d-blocks 1102-1105. In this 
case, root d-block represents a magazine, and each of the 
child d-blocks 1102-1105 represent articles in the magazine. 
Suppose that a request is made to PRINT the digital work 
represented by root d-block 1101 wherein the strict rule is 
followed. The rights for the root d-block 1101 and child 
d-blocks 1102-1105 are then examined. Root d-block 1101 
and child d-blocks 1102 and 1105 have been granted PRINT 
rights. Child d-block 1103 has not been granted PRINT 
rights and child d-block 1104 has PRINT rights conditioned 
on payment of a usage fee. 

Under the strict rule the PRINT right cannot be exercised 
because the child d-block does not have the PRINT right. 
Under the lenient rule, the result would be different. The 
digital works represented by child d-blocks 1102 and 1105 
could be printed and the digital work represented by d-block 
1104 could be printed so long as the usage fee is paid. Only 
the digital work represented by d-block 1103 could not be 
printed. This same result would be accomplished under the 
strict rule if the requests were directed to each of the 
individual digital works. 

The present invention supports various combinations of 
allowing and disallowing access. Moreover, as will be 
described below, the usage rights grammar permits the 
owner of a digital work to specify if constraints may be 
imposed on the work by a container part. The manner in 
which digital works may be sanctioned because of usage 
rights conflicts would be implementation specific and would 
depend on the nature of the digital works. 
Repositories 

Many of the powerful functions of repositories — such as 
their ability to "loan" digital works or automatically handle 
the commercial reuse of digital works — are possible because 
they are trusted systems. The systems are trusted because 
they are able to take responsibility for fairly and reliably 
carrying out the commercial transactions. That the systems 
can be responsible ("able to respond") is fundamentally an 
issue of integrity. The integrity of repositories has three 
parts: physical integrity, communications integrity, and 
behavioral integrity. 

Physical integrity refers to the integrity of the physical 
devices themselves. Physical integrity applies both to the 
repositories and to the protected digital works. Thus, the 
higher security classes of repositories themselves may have 
sensors that detect when tampering is attempted on their 
secure cases. In addition to protection of the repository 
itself, the repository design protects access to the content of 
digital works. In contrast with the design of conventional 
magnetic and optical devices — such as floppy disks, 
CD-ROMs, and videotapes — repositories never allow non- 
trusted systems to access the works directly. A maker of 
generic computer systems cannot guarantee that their plat- 
form will not be used to make unauthorized copies. The 
manufacturer provides generic capabilities for reading and 
writing information, and the general nature of the function- 
ality of the general computing device depends on it. Thus, a 
copy program can copy arbitrary data. This copying issue is 
not limited to general purpose computers. It also arises for 
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the unauthorized duplication of entertainment "software" executing on the hardware embodiment. Alternatively, the 

such as video and audio recordings by magnetic recorders. functional embodiment may be embedded in the hardware 

Again, the functionality of the recorders depends on their embodiment such as an Application Specific Integrated 

ability to copy and they have no means to check whether a Circuit (ASIC) chip. 

copy is authorized. In contrast, repositories prevent access to 5 The hardware embodiment of a repository will be 
the raw data by general devices and can test explicit rights enclosed in a secure housing which if compromised, may 
and conditions before copying or otherwise granting access. cause the repository to be disabled. The basic components of 
Information is only accessed by protocol between trusted the hardware embodiment of a repository are described with 
repositories. reference to FIG. 12. Referring to FIG. 12, a repository is 
. Communications integrity refers to the integrity of the 10 comprised of a processing means 1200, storage system 
communications channels between repositories. Roughly 1207, clock 1205 and external interface 1206. The process- 
speaking, communications integrity means that repositories ing means 1200 is comprised of a processor element 1201 
cannot be easily fooled by "telling them lies." Integrity in and processor memory 1202. The processing means 1201 
this case refers to the property that repositories will only provides controller, repository transaction and usage rights 
communicate with other devices that are able to present is transaction functions for the repository. Various functions in 
proof that they are certified repositories, and furthermore, the operation of the repository such as decryption and/or 
that the repositories monitor the communications to detect decompression of digital works and transaction messages 
"impostors" and malicious or accidental interference. Thus are also performed by the processing means 1200. The 
the security measures involving encryption, exchange of processor element 1201 may be a microprocessor or other 
digital certificates, and nonces described below are all 20 suitable computing component. The processor memory 1202 
security measures aimed at reliable communication in a would typically be further comprised of Read Only Memo- 
world known to contain active adversaries. ries (ROM) and Random Access Memories (RAM). Such 
Behavioral integrity refers to the integrity in what reposi- memories would contain the software instructions utilized 
tories do. What repositories do is determined by the software by the processor element 1201 in performing the functions 
that they execute. The integrity of the software is generally 25 of the repository. 

assured only by knowledge of its source. Restated, a user The storage system 1207 is further comprised of descrip- 

will trust software purchased at a reputable computer store tor storage 1203 and content storage 1204. The description 

but not trust software obtained off a random (insecure) tree storage 1203 will store the description tree for the digital 

server on a network. Behavioral integrity is maintained by work and the content storage will store the associated 

requiring that repository software be certified and be dis- 30 content. The description tree storage 1203 and content 

tributed with proof of such certification, i.e. a digital cer- storage 1204 need not be of the same type of storage 

tificate. The purpose of the certificate is to authenticate that medium, nor are they necessarily on the same physical 

the software has been tested by an authorized organization, device. So for example, the descriptor storage 1203 may be 

which attests that the software does what it is supposed to do stored on a solid state storage (for rapid retrieval of the 

and that it does not compromise the behavioral integrity of 35 description tree information), while the content storage 1204 

a repository. If the digital certificate cannot be found in the may be on a high capacity storage such as an optical disk, 

digital work or the master repository which generated the The clock 1205 is used to time-stamp various time based 

certificate is not known to the repository receiving the conditions for usage rights or for metering usage fees which 

software, then the software cannot be installed. may be associated with the digital works. The clock 1205 

In the description of FIG. 2, it was indicated that reposi- 40 will have an uninlerruptable power supply, e.g. a battery, in 
tories come in various forms. All repositories provide a core order to maintain the integrity of the time-stamps. The 
set of services for the transmission of digital works. The external interface means 1206 provides for the signal con- 
manner in which digital works are exchanged is the basis for nection to other repositories and to a credit server. The 
all transaction between repositories. The various repository external interface means 1206 provides for the exchange of 
types differ in the ultimate functions that they perform. 45 signals via such standard interfaces such as RS-232 or 
Repositories may be devices themselves, or they may be Personal Computer Manufacturers Card Industry Associa- 
incorporated into other systems. An example is the rendering tion (PCMCIA) standards, or FDDI. The external interface 
repository 205 of FIG. 2. means 1206 may also provide network connectivity. 

A repository will have associated with it a repository The functional embodiment of a repository is described 
identifier. Typically, the repository identifier would be a 50 with reference to FIG. 13. Referring to FIG. 13, the func- 
unique number assigned to the repository at the time of tional embodiment is comprised of an operating system 
manufacture. Each repository will also be classified as being 1301, core repository services 1302, usage transaction han- 
in a particular security class. Certain communications and dlers 1303, repository specific functions, 1304 and a user 
transactions may be conditioned on a repository being in a interface 1305. The operating system 1301 is specific to the 
particular security class. The various security classes are 55 repository and would typically depend on the type of pro- 
described in greater detail below. cessor being used. The operating system 1301 would also 

As a prerequisite to operation, a repository will require provide the basic services for controlling and interfacing 
possession of an identification certificate. Identification cer- between the basic components of the repository, 
tificates are encrypted to prevent forgery and are issued by The core repository services 1302 comprise a set of 
a Master repository. A master repository plays the role of an 60 functions required by each and every repository. The core 
authorization agent to enable repositories to receive digital repository services 1302 include the session initiation trans- 
works. Identification certificates must be updated on a actions which are defined in greater detail below. This set of 
periodic basis. Identification certificates are described in services also includes a generic ticket agent which is used to 
greater detail below with respect to the registration transac- "punch" a digital ticket and a generic authorization server 
lion. 65 for processing authorization specifications. Digital tickets 

A repository has both a hardware and functional embodi- and authorizations are specific mechanisms for controlling 

mem. The functional embodiment is typically software the distribution and use of digital works and are described 
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and more detail below. Note that coupled to the core 
repository services are a plurality of identification certifi- 
cates 1306. The identification certificates 1306 are required 
to enable the use of the repository. 

The usage transactions handler 1303 comprise function- 
ality for processing access requests to digital works and for 
billing fees based on access. The usage transactions sup- 
ported will be different for each repository type. For 
example, it may not be necessary for some repositories to 
handle access requests for digital works. 

The repository specific functionality 1304 comprises 
functionality that is unique to a repository. For example, the 
master repository has special functionality for issuing digital 
certificates and maintaining encryption keys. The repository 
specific functionality 1304 would include the user interface 
implementation for the repository. 
Repository Security Classes 

For some digital works the losses caused by any indi- 
vidual instance of unauthorized copying is insignificant and 
the chief economic concern lies in assuring the convenience 
of access and low-overhead billing. In such cases, simple 
and inexpensive handheld repositories and network-based 
workstations may be suitable repositories, even though the 
measures and guarantees of security are modest. 

At the other extreme, some digital works such as a digital 
copy of a first run movie or a bearer bond or stock certificate 
would be of very high value so that it is prudent to employ 
caution and fairly elaborate security measures to ensure that 
they are not copied or forged. A repository suitable for 
holding such a digital work could have elaborate measures 
for ensuring physical integrity and for verifying authoriza- 
tion before use. 

By arranging a universal protocol, all kinds of repositories 
can communicate with each other in principle. However, 
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TABLE 2-continued 
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REPOSITORY SECURITY LEVELS 

Level Description of Security 

only through the transmission transaction protocol. 
4 Like the previous class except that high level encryption is used on 
all communications. Sensors arc used to record attempts at 
physical and electronic tampering. After such tampering, the 
repository will not perform other transactions until it has reported 
such tampering to a designated server. 
Like the previous class except that if the physical or digital 
attempts at tampering exceed some preset thresholds that 
threaten the physical integrity of the repository or the integrity of 
digital and cryptographic barriers, then the repository will save 
only document description records of history but wiil erase or 
destroy any digital identifiers that could be misused if released to 
an unscrupulous party. It also modifies any certificates of 
authenticity to indicate that the physical system has been 
compromised. It also erases the contents of designated documents. 
Like the previous class except that the repository will attempt 
wireless communication to report tampering and will employ noisy 
alarms. 

10 This would correspond to a very high level of security. This server 
would maintain constant communications to remote security 
systems reporting transactions, sensor readings, and attempts to 
circumvent security. 
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The characterization of security levels described in Table 
2 is not intended to be fixed. More important is the idea of 
having different security levels for different repositories. It is 
anticipated that new security classes and requirements will 
evolve according to social situations and changes in tech- 
nology. 

Repository User Interface 
A user interface is broadly defined as the mechanism by 



which a user interacts with a repository in order to invoke 
creators of some works will want to specify that their works 35 transactions to gain access to a digital work, or exercise 

usage rights. As described above, a repository may be 



will only be transferred to repositories whose level of 
security is high enough. For this reason, document reposi- 
tories have a ranking system for classes and levels of 
security. The security classes in the currently preferred 
embodiment are described in Table 2. 

TABLE 2 

REPOSITORY SECURITY LEVELS 
Level Description of Security 

0 Open system. Document transmission is unencrypted. No digital 
certificate is required for identification. The security of the system 
depends mostly on user honesty, since only modest knowledge may 
be needed to circumvent the security measures. The repository 

has no provisions for preventing unauthorized programs from 
running and accessing or copying files. The system does not 
prevent the use of removable storage and does not encrypt stored 
files. 

1 Minimal security. Like toe previous class except that stored files 
are minimally encrypted, including ones on removable storage. 

2 Basic security. Like the previous class except that special tools 
and knowledge are required to compromise the programming, the 
contents of the repository, or the state of the clock. All digital 
communications are encrypted. A digital certificate is provided as 
identification. Medium level encryption is used. Repository 
identification number is unforgeablc. 

3 General security. Like the previous class plus the requirement of 
special tools are needed to compromise the physical integrity of the 
repository and that modest encryption is used on all transmissions. 
Password protection is required to use the local user interface. The 
digital clock system cannot be reset without authorization. No 
works would be stored on removable storage. When executing 
works as programs, it runs them in their own address space and 
does not give them direct access to any file storage or other 
memory containing system code or works. They can access works 
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embodied in various forms. The user interface for a reposi- 
tory will differ depending on the particular embodiment. The 
user interface may be a graphical user interface having icons 
representing the digital works and the various transactions 
that may be performed. The user interface may be a gener- 
ated dialog in which a user is prompted for information. 

The user interface itself need not be part of the repository. 
As a repository may be embedded in some other device, the 
user interface may merely be a part of the device in which 
the repository is embedded. For example, the repository 
could be embedded in a "card" that is inserted into an 
available slot in a computer system. The user interface may 
be combination of a display, keyboard, cursor control device 
and software executing on the computer system. 

At a minimum, the user interface must permit a user to 
input information such as access requests and alpha numeric 
data and provide feedback as to transaction status. The user 
interface will then cause the repository to initiate the suitable 
transactions to service the request. Other facets of a particu- 
lar user interface will depend on the functionality that a 
repository will provide. 
Credit Servers 

In the present invention, fees may be associated with the 
exercise of a right. The requirement for payment of fees is 
described with each version of a usage right in the usage 
rights language. The recording and reporting of such fees is 
performed by the credit server. One of the capabilities 
enabled by associating fees with rights is the possibility of 
supporting a wide range of charging models. The simplest 
model, used by conventional software, is that there is a 
single fee at the time of purchase, after which the purchaser 
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obtains unlimited rights to use the work as often and for as 
long as he or she wants. Alternative models, include metered 
use and variable fees. A single work can have different fees 
for different uses. For example, viewing a photograph on a 
display could have different fees than making a hardcopy or 
including it in a newly created work. A key to these 
alternative charging models is to have a low overhead means 
of establishing fees and accounting for credit on these 
transactions. 

A credit server is a computational system that reliably 
authorizes and records these transactions so that fees are 
billed and paid. Hie credit server reports fees to a billing 
clearinghouse. The billing clearinghouse manages the finan- 
cial transactions as they occur. As a result, bills may be 
generated and accounts reconciled. Preferably, the credit 
server would store the fee transactions and periodically 
communicate via a network with billing clearinghouse for 
reconciliation. In such an embodiment, communications 
with the billing clearinghouse would be encrypted for integ- 
rity and security reasons. In another embodiment, the credit 
server acts as a "debit card" where transactions occur in 
"real-time" against a user account. 

A credit server is comprised of memory, a processing 
means, a clock, and interface means for coupling to a 
repository and a financial institution (e.g. a modem). The 
credit server will also need to have security and authenti- 
cation functionality. These elements are essentially the same 
elements as those of a repository. Thus, a single device can 
be both a repository and a credit server, provided that it has 
the appropriate processing elements for carrying out the 
corresponding functions and protocols. Typically, however, 
a credit server would be a card-sized system in the posses- 
sion of the owner of the credit. The credit server is coupled 
to a repository and would interact via financial transactions 
as described below. Interactions with a financial institution 
may occur via protocols established by the financial insti- 
tutious themselves. 

In the currently preferred embodiment credit servers 
associated with both the server and the repository report the 
financial transaction to the billing clearinghouse. For 
example, when a digital work is copied by one repository to 
another for a fee, credit servers coupled to each of the 
repositories will report the transaction to the billing clear- 
inghouse. This is desirable in that it insures that a transaction 
will be accounted for in the event of some break in the 
communication between a credit server and the billing 
clearinghouse. However, some implementations may 
embody only a single credit server reporting the transaction 
to minimize transaction processing at the risk of losing some 
transactions. 
Usage Rights Language 

The present invention uses statements in a high level 
"usage rights language" to define rights associated with 
digital works and their parts. Usage rights statements are 
interpreted by repositories and are used to determine what 
transactions can be successfully carried out for a digital 
work and also to determine parameters for those transac- 
tions. For example, sentences in the language determine 
whether a given digital work can be copied, when and how 
it can be used, and what fees (if any) are to be charged for 
that use. Once the usage rights statements are generated, 
they are encoded in a suitable form for accessing during the 
processing of transactions. 

Defining usage rights in terms of a language in combi- 
nation with the hierarchical representation of a digital work 
enables the support of a wide variety of distribution and fee 
schemes. An example is the ability to attach multiple ver- 
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sions of a right to a work. So a creator may attach a PRINT 
right to make 5 copies for $10.00 and a PRINT right to make 
unlimited copies for $100.00. A purchaser may then choose 
which option best fits bis needs. Another example is that 

5 rights and fees are additive. So in the case of a composite 
work, the rights and fees of each of the components works 
is used in determining the rights and fees for the work as a 
whole. Other features and benefits of the usage rights 
language will become apparent in the description of distri- 

10 bution and use scenarios provided below. 

The basic contents of a right are illustrated in FIG. 14. 
Referring to FIG. 14, a right 1450 has a transactional 
component 1451 and a specifications component 1452. A 
right 1450 has a label (e.g. COPY or PRINT) which indicate 

.5 the use or distribution privileges that are embodied by the 
right. The transactional component 1451 corresponds to a 
particular way in which a digital work may be used or 
distributed. The transactional component 1451 is typically 
embodied in software instructions in a repository which 

io implement the use or distribution privileges for the right. 
The specifications components 1452 are used to specify 
conditions which must be satisfied prior to the right being 
exercised or to designate various transaction related param- 
eters. In the currently preferred embodiment, these specifi- 

5 cations include copy count 1453, Fees and Incentives 1454, 
Time 1455, Access and Security 1456 and Control 1457. 
Each of these specifications will be described in greater 
detail below with respect to the language grammar elements. 
The usage rights language is based on the grammar 

o described below. A grammar is ■ a convenient means for 
defining valid sequence of symbols for a language. In 
describing the grammar the notation "[a|b|c]" is used to 
indicate distinct choices among alternatives. In this example, 
a sentence can have either an "a", "b" or "c". It must include 

5 exactly one of them. The braces { } are used to indicate 
optional items. Note that brackets, bars and braces are used 
to describe the language of usage rights sentences but do not 
appear in actual sentences in the language. 
In contrast, parentheses are part of the usage rights 

0 language. Parentheses are used to group items together in 
lists. The notation (x*) is used to indicate a variable length 
list, that is, a list containing one or more items of type x. The 
notation (x)* is used to indicate a variable number of lists 
containing x. 

5 Keywords in the grammar are words followed by colons. 
Keywords are a common and very special case in the 
language. They are often used to indicate a single value, 
typically an identifier. In many cases, the keyword and the 
parameter are entirely optional. When a keyword is given, it 

0 often takes a single identifier as its value. In some cases, the 
keyword takes a list of identifiers. In the usage rights 
language, time is specified in an hours:minutes:seconds (or 
hh:mm:ss) representation. Time zone indicators, e.g. PDT 
for Pacific Daylight Time, may also be specified. Dates are 

5 represented as year/month/day (or YYYY/MMM/DD). Note 
that these time and date representations may specify 
moments in time or units of time Money units are specified 
in terms of dollars. 
Finally, in the usage rights language, various "things" will 

o need to interact with each other. For example, an instance of 
a usage right may specify a bank account, a digital ticket, 
etc. Such things need to be identified and are specified herein 
using the suffix "-ID." 
The Usage Rights Grammar is listed in it's entirety in 

5 FIG. 15 and is described below. 

Grammar element 1501 "Digital Work Righls;- 
(Rights*)" define the digital work rights as a set of rights. 
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The set of rights attached to a digital work define how that against catastrophic failure of equipment. However, the 

digital work may be transferred, used, performed or played. making of uncontrolled backup copies is inherently at odds 

A set of rights will attach to the entire digital work and in the with the ability to control usage, since an uncontrolled 

case of compound digital works, each of the components of backup copy can be kept and then restored even after the 

the digital work. The usage rights of components of a digital 5 authorized copy was sold. 

may be different. The File management rights enable the making and restor- 

Grammar element 1502 "Right:-(Right-Code {Copy- ing of backup copies in a way that respects usage rights, 

Count} {Control-Spec} {Time-Spec } {Access-Spec} {Fee- honoring the requirements of both the copy owner and the 

Spec})" enumerates the content of a right. Each usage right rights grantor and revenue owner. Backup copies of work 

must specify a right code. Each right may also optionally 1Q descriptions (including usage rights and fee data) can be sent 

specify conditions which must be satisfied before the right under appropriate protocol and usage rights control to other 

can be exercised. These conditions are copy count, control, document repositories of sufficiently high security. Further 

time, access and fee conditions. In the currently preferred rights permit organization of digital works into folders 

embodiment, for the optional elements, the following which themselves are treated as digital works and whose 

defaults apply: copy count equals 1, no time limit on the use contents may be "hidden" from a party seeking to determine 

of the right, no access tests or a security level required to use 15 the contents of a repository. 

the right and no fee is required. These conditions will each Backup To make a backup copy of a digital work as 

be described in greater detail below. protection against media failure. 

It is important to note that a digital work may have Restore To restore a backup copy of a digital work, 

multiple versions of a right, each having the same right code. Delete To delete or erase a copy of a digital work. 

The multiple version would provide alternative conditions 20 Folder To create and name folders, and to move files and 

and fees for accessing the digital work. folders between folders. 

Grammar element 1503 "Righi-Code:-Render- Directory To hide a folder or it's contents. 

Code|Transport-Code|File-Management-Code|Derivative- Grammar element 1507 "Derivative-Works-Code: 

Works-Code Configuration-Code" distinguishes each of the [Extract|Embed|Edit {Process: Process-ID}] {Next-Copy- 

specific rights into a particular right type (although each 25 Rights: Next-Set-of Rights}" lists a category of rights 

right is identified by distinct right codes). In this way, the involving the use of a digital work to create new works, 

grammar provides a catalog of possible rights that can be Extract To remove a portion of a work, for the purposes of 

associated with parts of digital works. In the following, creating a new work, 

rights are divided into categories for convenience in describ- Embed To include a work in an existing work, 

ing them. 30 Edit To alter a digital work by copying, selecting and 

Grammar element 1504 "Render- Code >[Play: {Player: modifying portions of an existing digital work. 

Player-ID }|Print: {Printer: Printer-ID}]" lists a category of Grammar element 1508 "Configuration-Code:- 

rights all involving the making of ephemeral, transitory, or InstaUjUninstalT lists a category of rights for in stalling and 

non-digital copies of the digital work. After use the copies uninstalling software on a repository (typically a rendering 

are erased. 35 repository.) This would typically occur for the installation of 

Play A process of rendering or performing a digital work on a new type of player within the rendering repository. 

some processor. This includes such things as playing Install: To install new software on a repository. 

digital movies, playing digital music, playing a video Uninstall: To remove existing software from a repository. 

game, running a computer program, or displaying a Grammar element 1509 "Next-Set-of-Rights:-{(Add: 

document on a display. 40 Set-Of-Rights)} {(Delete: Set-Of-Rights)} {(Replace: Set- 
Print To render the work in a medium that is not further Of-Rights)} {(Keep: Set-Of-Rights)}" defines how rights 

protected by usage rights, such as printing on paper. are carried forward for a copy of a digital work. If the 

Grammar element 1505 "Transport-Code:- Next-Copy-Rights is not specified, the rights for the next 

[Copy|Transfer[Loan {Remaining-Rights: Next-Set-of- copy aire me same as those of the current copy. Otherwise, 

Rights }]{(Next-Copy-Rights: Next-Set of Rights)}" lists a 45 the set of rights for the next copy can be specified. Versions 

category of rights involving the making of persistent, usable of rights after Add: are added to the current set of rights, 

copies of the digital work on other repositories. The optional Rights after Delete: are deleted from the current set of rights. 

Next-Copy-Rights determine the rights on the work after it If only right codes are listed after Delete:, then all versions 

is transported. If this is not specified, then the rights on the of rights with those codes are deleted. Versions of rights after 

transported copy are the same as on the original. The 50 Replace: subsume all versions of rights of the same type in 

optional Remaining-Rights specify the rights that remain the current set of rights. 

with a digital work when it is loaned out. If this is not If Remaining-Rights is not specified, then there are no 

specified, then the default is that no rights can be exercised rights for the original after all Loan copies are loaned out. If 

when it is loaned out. Remaining-Rights is specified, then the Keep: token can be 

Copy Make a new copy of a work ■ 55 used to simplify the expression of what rights to keep 

Transfer Moving a work from one repository to another. behind. A list of right codes following keep means that all of 

Loan Temporarily loaning a copy to another repository for the versions of those listed rights are kept in the remaining 

a specified period of time. copy. This specification can be overridden by subsequent 

Grammar element 1506 "File-Management-Code:- Delete: or Replace: specifications. 

Backup {Back-Up-Copy-Rights: Next-Set-of 60 Copy Count Specification 

Rights}|Restore|Delete|Folder|Directory {Name:Hide- For various transactions, it may be desirable to provide 

Local|Hide-Remote}{Parts:Hide-Local|Hide-Remote}" lists some limit as to the number of "copies" of the work which 

a category of rights involving operations for file may be exercised simultaneously for the right. For example, 

management, such as the making of backup copies to protect it may be desirable to limit the number of copies of a digital 

the copy owner against catastrophic equipment failure. 65 work that may be loaned out at a lime or viewed at a time. 

Many software licenses and also copyright law give a Grammar element 1510 "Copy-Count:-(Copies: positive- 
copy owner the right to make backup copies to protect integer|0|unlimited)" provides a condition which defines the 
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number of "copies" of a work subject to the right. A copy Grammar element 1515 "Meter- Time:«Time-Remaining: 

count can be 0, a fixed number, or unlimited. The copy-count Remaining- Use" is used to define a "meter time," that is, a 

is associated with each right, as opposed to there being just measure of the time that the right is actually exercised. It 

a single copy-count for the digital work. The Copy-Count differs from the Sliding-Interval specification in that the time 

for a right is decremented each time that a right is exercised. 5 that the digital work is in use need not be continuous. For 

When the Copy-Count equals zero, the right can no longer example, if the rights guarantee three days of access, those 

be exercised. If the Copy-Count is not specified, the default days couId be spread out over a montD . with this 

r ° T 1 <; 'fi specification, the rights can be exercised until the meter time 

n! ro ' specification ..... is exhausted or the expiration date is reached, whichever 

Rights and fees depend in general on rights granted by the - r 

creator as well as further restrictions imposed by later n m S . ' ... 

distributors. Control specifications deal with interactions ^ m ^ m ^-^ : *\ ime ; Umt 

between the creators and their distributors governing the Mart-lime:- lunc-Umt 

imposition of further restrictions and fees. For example, a Use-puration:-Time-Unit 

distributor of a digital work may not want an end consumer Ml of the hme specifications include time-unit specifications 

of a digital work to add fees or otherwise profit by com- 35 m me j r ultimate instantiation. 

mercially exploiting the purchased digital work. Security Class and Authorization Specification 

Grammar element 1511 "Control-Spec:-(Control: The present invention provides for various security 
{Restrictable|Unrestrictable} {Unchargeable| Chargeable})" mechanisms to be introduced into a distribution or use 
provides a condition to specify the effect of usage rights and scheme. Grammar element 1516 "Access-Spec: =({SC: 
fees of parents on the exercise of the right. A digital work is 20 Security-Class} {Authorization: Authorization-ID* } 
restrictable if higher level d-blocks can impose further {Other-Authorization: Authorization-ID*} {Ticket: Ticket- 
restrictions (time specifications and access specifications) on 10})" provides a means for restricting access and transmis- 
the right. It is unrestrictable if no further restrictions can be sion. Access specifications can specify a required security 
imposed. The default setting is restrictable. A right is class for a repository to exercise a right or a required 
unchargeable if no more fees can be imposed on the use of 25 authorization test that must be satisfied, 
the right. It is chargeable if more fees can be imposed. The The keyword "SC:" is used to specify a minimum security 
default is chargeable. level for the repositories involved in the access. If "SC:" is 
Time Specification not specified, the lowest security level is acceptable. 

It is often desirable to assign a start date or specify some The optional "Authorization:" keyword is used to specify 

duration as to when a right may be exercised. Grammar 30 required authorizations on the same repository as the work, 

element 1512 "Time-Spec:=({Fixed-Interval|Sliding- The optional "Other-Authorization:" keyword is used to 

Intei^al|Meter-Time} Until: Expiration-Date)" provides for specify required authorizations on the other repository in the 

specification of time conditions on the exercise of a right. transaction. 

Rights may be granted for a specified time. Different kinds The optional "Ticket:" keyword specifies the identity of a 

of time specifications are appropriate for different kinds of 35 ticket required for the transaction. A transaction involving 

rights. Some rights may be exercised during a fixed and digital tickets must locate an appropriate digital ticket agent 

predetermined duration. Some rights may be exercised for who can "punch" or otherwise validate the ticket before the 

an interval that starts the first time that the right is invoked transaction can proceed. Tickets are described in greater 

by some transaction. Some rights may be exercised or are detail below. 

charged according to some kind of metered time, which may 40 In a transaction involving a repository and a document 

be split into separate intervals. For example, a right to view server, some usage rights may require that the repository 

a picture for an hour might be split into six ten minute have a particular authorization, that the server have some 

viewings or four fifteen minute viewings or twenty three authorization, or that both repositories have (possibly 

minute viewings. different) authorizations. Authorizations themselves are 

The terms "time" and "date" are used synonymously to 45 digital works (hereinafter referred to as an authorization 
refer to a moment in time. There are several kinds of time object) that can be moved between repositories in the same 
specifications. Each specification represents some limitation manner as other digital works. Their copying and transfer- 
on the times over which the usage right applies. The ring is subject to the same rights and fees as other digital 
Expiration-Date specifies the moment at which the usage works. A repository is said to have an authorization if that 
right ends. For example, if the Expiration-Date is "Jan. 1, 50 authorization object is contained within the repository. 
1995," then the right ends at the first moment of 1995. If the In some cases, an authorization may be required from a 
Expiration-Date is specified as * forever*, then the rights are source other than the document server and repository. An 
interpreted as continuing without end. If only an expiration authorization object referenced by an Authorization-ID can 
date is given, then the right can be exercised as often as contain digital address information to be used to set up a 
desired until the expiration date. 55 communications link between a repository and the authori- 

Grammar element 1513 "Fixed-Interval: -From: Start- zation source. These are analogous to phone numbers. For 

Time" is used to define a predetermined interval that runs such access tests, the communication would need to be 

from the start time to the expiration date. established and authorization obtained before the right could 

Grammar element 1514 "Sliding-Interval: -Interval: Use- be exercised. 

Duration" is used to define an indeterminate (or "open") 60 For one-time usage rights, a variant on this scheme is to 

start time. It sets limits on a continuous period of time over have a digital ticket. A ticket is presented to a digital ticket 

which the contents are accessible. The period starts on the agent, whose type is specified on the ticket. In the simplest 

first access and ends after the duration has passed or the case, a certified generic ticket agent, available on all 

expiration date is reached, whichever comes first. For repositories, is available to "punch" the ticket. In other 

example, if the right gives 10 hours of continuous access, the 65 cases, the ticket may contain addressing information for 

use-duration would begin when the first access was made locating a "special" ticket agent. Once a ticket has been 

and end 10 hours later. punched, it cannot be used again for the same kind of 
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transaction (unless it is unpunched or refreshed in the 
manner described below.) Punching includes marking the 
ticket with a timestamp of the date and time it was used. 
Tickets are digital works and can be copied or transferred 
between repositories according to their usage rights. In the 5 
currently preferred embodiment, a "punched" ticket 
becomes "unpunched" or "refreshed" when it is copied or 
extracted. The Copy and Extract operations save the date 
and time as a property of the digital ticket. When a ticket 
agent is given a ticket, it can simply check whether the 3Q 
digital copy was made after the last time that it was punched. 
Of course, the digital ticket must have the copy or extract 
usage rights attached thereto. 

The capability to unpunch a ticket is inportant in the 
following cases: 

A digital work is circulated at low cost with a limitation that 15 

it can be used only once. 
A digital work is circulated with a ticket that can be used 

once to give discounts on purchases of other works. 
A digital work is circulated with a ticket (included in the 

purchase price and possibly embedded in the work) that 20 

can be used for a future upgrade. 

In each of these cases, if a paid copy is made of the digital 
work (including the ticket) the new owner would expect to 
get a fresh (unpunched) ticket, whether the copy seller has 
used the work or not. In contrast, loaning a work or simply 25 
transferring it to another repository should not revitalize the 
ticket. 

Usage Fees and Incentives Specification 

The billing for use of a digital work is fundamental to a 
commercial distribution system. Grammar Element 1517 30 
"Fee -Spec : = {Scheduled-Discount} Regular-Fee- 
Spec|Scheduled-Fee-Spec|Markup-Spec" provides a range 
of options for billing for the use of digital works. 

A key feature of this approach is the development of 
low-overhead billing for transactions in potentially small 35 
amounts. Thus, it becomes feasible to collect fees of only a 
few cents each for thousands of transactions. 

The grammar differentiates between uses where the 
charge is per use from those where it is metered by the time 
unit. Transactions can support fees that the user pays for 40 
using a digital work as well as incentives paid by the right 
grantor to users to induce them to use or distribute the digital 
work. 

The optional scheduled discount refers to the rest of the 
fee specification — discounting it by a percentage over time. 45 
If it is not specified, then there is no scheduled discount. 
Regular fee specifications are constant over time. Scheduled 
fee specifications give a schedule of dates over which the fee 
specifications change. Markup specifications are used in 
d-blocks for adding a percentage to the fees already being 50 
charged. 

Grammar Element 1518 "Scheduled-Discount:- 
(Scheduled-Discount: (Time-Spec Percentage)*)" A 
Scheduled-Discount is a essentially a scheduled modifier of 
any other fee specification for this version of the right of the 55 
digital work. (It does not refer to children or parent digital 
works or to other versions of rights.). It is a list of pairs of 
times and percentages. The most recent time in the list that 
has not yet passed at the time of the transaction is the one in 
effect. The percentage gives the discount percentage. For 60 
example, the number 10 refers to a 10% discount. 

Grammar Element 1519 "Regular-Fee-Spec:- 
({Fee:|Incentive:} [Per-Use-Spcc|Metered-Rate-Spec)Best- 
Price-Spec|Call-For-Price-Spec] {Min: Money-Unit Per: 
Time-Spec}{Max: Money-Unit Per: Time-Spec} To: 65 
Account-ID)" provides for several kinds of fee specifica- 
tions. 
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Fees are paid by the copy-owner/user to the revenue- 
owner if Fee: is specified. Incentives are paid by the 
revenue-owner to the user if Incentive: is specified. If the 
Min: specification is given, then there is a minimum fee to 
be charged per time-spec unit for its use. If the Max: 
specification is given, then there is a maximum fee to be 
charged per time-spec for its use. When Fee: is specified, 
Account-ID identifies the account to which the fee is to be 
paid. When Incentive: is specified, Account-ID identifies the 
account from which the fee is to be paid. 

Grammar element 1520 "Per-Use-Spec:=Per-Use: 
Money-unit" defines a simple fee to be paid every time the 
right is exercised, regardless of how much time the trans- 
action takes. 

Grammar element 1521 "Metered-Rate-Spec: -Metered: 
Money-Unit Per: Time-Spec" defines a metered-rate fee paid 
according to how long the right is exercised. Thus, the time 
it takes to complete the transaction determines the fee. 

Grammar element 1522 "Best-Price-SpeoBest-Price: 
Money-unit Max: Money-unit" is used to specify a best- 
price that is determined when the account is settled. This 
specification is to accommodate special deals, rebates, and 
pricing that depends on information that is not available to 
the repository. All fee specifications can be combined with 
tickets or authorizations that could indicate that the con- 
sumer is a wholesaler or that he is a preferred customer, or 
that the seller be authorized in some way. The amount of 
money in the Max: field is the maximum amount that the use 
will cost. This is the amount that is tentatively debited from 
the credit server. However, when the transaction is ulti- 
mately reconciled, any excess amount will be returned to the 
consumer in a separate transaction. 

Grammar element 1523 "CaU-For-Price-Spec:=Call-For- 
Price " is similar to a "Best-Price-Spec" in that it is intended 
to accommodate cases where prices are dynamic. A Call- 
For-Price Spec requires a communication with a dealer to 
determine the price. This option cannot be exercised if the 
repository cannot communicate with a dealer at the time that 
the right is exercised. It is based on a secure transaction 
whereby the dealer names a price to exercise the right and 
passes along a deal certificate which is referenced or 
included in the billing process. 

Grammar element 1524 "Scheduled-Fee-Spec:- 
(Schedule: (Time-Spec Regular-Fee-Spec)*)" is used to 
provide a schedule of dates over which the fee specifications 
change. The fee specification with the most recent date not 
in the future is the one that is in effect. This is similar to but 
more general than the scheduled discount. It is more general, 
because it provides a means to vary the fee agreement for 
each time period. 

Grammar element 1525 "Markup-SpeoMarkup: per- 
centage To: Account -ID" is provided for adding a percentage 
to the fees already being charged. For example, a 5% 
markup means that a fee of 5% of cumulative fee so far will 
be allocated to the distributor. A markup specification can be 
applied to all of the other kinds of fee specifications. It is 
typically used in a shell provided by a distributor. It refers 
to fees associated with d-blocks that are parts of the current 
d-block. This might be a convenient specification for use in 
taxes, or in distributor overhead. 
Examples of Sets of Usage Rights 
((Play) (Transfer(SC: 3)) (Delete) 

This work can be played without requirements for fee or 
authorization on any rendering system. It can be transferred 
to any other repository of security level 3 or greater. It can 
be deleted. 
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((Play) (Transfer (SC: 3)) (Delete) (Backup) (Restore (Fee: of the Play, Print and Backup rights. The second version of 

Per-Use: $5 To: Account-ID -678))) the Loan right is free. None of the original rights are 

Same as the previous example plus rights for backup and applicable. However a right to Play the work at the specified 

restore. The work can be backed up without fee. It can be metered rate is added. 

restored for a $5 fee payable to the account described by 5 ((Play Player: Player-Small-Screen-123-ID) (Embed (Fee: 

Account-ID-678. Per-Use $.0.1 To: Account-678-ID)) (Copy (Fee: Per-Use 

((Play) (Transfer (SC: 3)) (Copy (SC:3XFee: Per-Use: $5 $1.00 To: Account-678-ID))) 

To: Account-ID-678)) (Delete 0 nceQuve: Per-Use: $2.50 The digital work can be played on any player with the 

To: Account-ID-678))) identifier Player-Small-Screen-123-ID. It can be embedded 

This work can be played, transferred, copied, or deleted. 10 in a larger work. The embedding requires a modest one cent 

Copy or transfer operations can take place only with reposi- registration fee to Account-678-ID. Digital copies can be 

tories of security level three or greater. The fee to make a made for $1.00. 

copy is $5 payable to Account-ID-678. If a copy is deleted, Repository Transactions 

then an incentive of $2.50 is paid to the former copy owner. When a user requests access to a digital work, the 
((Play) (Transfer (SC: 3)) Copy (SC: 3) (Fee: Per-Use: $10 15 repository will initiate various transactions. The combina- 
To: Account-ID-678)) Delete) (Backup) (Restore (SC: 3) tion of transactions invoked will depend on the sperifica- 
(Fee: Per-Use: $5 To: Account-ID-678))) tions assigned for a usage right. There are three basic types 
Same as the previous example plus fees for copying. The of transactions, Session Initiation Transactions, Financial 
work can be copied digitally for a fee of $10 payable to Transactions and Usage Transactions. Generally, session 
Account-ID-678. The repository on which the work is 20 initiation transactions are initiated first to establish a valid 
copied or restored must be at security level 3 or greater. session. When a valid session is established, transactions 
((Play) (Transfer (SC: 3)) (Copy Authorization: License- corresponding to the various usage rights are invoked. 
123-ID (SC: 3))) Finally, request specific transactions are performed. 
The digital work can be played, transferred, or copied. Transactions occur between two repositories (one acting 
Copies or transfers must be on repositories of security level 25 as a server), between a repository and a document playback 
3 or greater. Copying requires the license License-123-ID platform (e.g. for executing or viewing), between a reposi- 
issued to the copying repository. None of the rights require tory and a credit server or between a repository and an 
fees. authorization server. When transactions occur between more 
((Play) (Print Printer: Printer-567-ID (Fee: Per-Use: $1 To: than one repository, it is assumed that there is a reliable 
Account-ID-678))) 30 communication channel between the repositories. For 
This work can be played for free. It can be printed on any example, this could be a TCP/IP channel or any other 
printer with the identifier Printer-567-ID for a fee of $1 commercially available channel that has built-in capabilities 
payable to the account described by Account-ID-678. for detecting and correcting transmission errors. However, it 
((Play Player: Player-876-ID) (From: 94/02/14 Until: 95/02/ is not assumed that the communication channel is secure. 
15) (Fee: Metered: $0.01 Per: 0:1:0 Min: $0.25 Per: 0/1/0 35 Provisions for security and privacy are part of the require- 
To: Account-ID-567)) ments for specifying and implementing repositories and thus 
This work can be played on any player holding the ID form the need for various transactions. 
Player-876-ID. The time of this right is from Feb. 14, 1994 Message Transmission 

until Feb. 15, 1995. The fee for use is one cent per minute Transactions require that there be some communication 
with a minimum of 25 cents in any day that it is used, 40 between repositories. Communication between repositories 
payable to the account described by Account-ID-567. occurs in units termed as messages. Because the communi- 
((Play) (Transfer) (Delete) (Loan 2(Delete: Transfer Loan))) cation line is assumed to be unsecure, all communications 
This work can be played, transferred, deleted, or loaned. with repositories that are above the lowest security class are 
Up to two copies can be loaned out at a time. The loaned encrypted utilizing a public key encryption technique. Pub- 
copy has the same rights except that it cannot be transferred. 45 lie key encryption is a well known technique in the encryp- 
When both copies are loaned out, no rights can be exercised tion arts. The term key refers to a numeric code that is used 
on the original on the repository. with encryption and decryption algorithms. Keys come in 
((Play) (Transfer) (Delete) (Backup) (Restore (SC:3)) (Loan pairs, where "writing keys" are used to encrypt data and 
2 Remaining-Copy-Rights: (Delete: Play Transfer) Next- "checking keys" are used to decrypt data. Both writing and 
Set-of-Rights: (Delete: Transfer Loan))) 50 checking keys may be public or private. Public keys are 
Similar to previous example. Rights to Backup and those that are distributed to others. Private keys are main- 
Restore the work are added, where restoration requires a tained in confidence. 

repository of at least security level three. When all copies of Key management and security is instrumental in the 

the work are loaned out, the remaining copy cannot be success of a public key encryption system. In the currently 

played or transferred. 55 preferred embodiment, one or more master repositories 

((Play) (Transfer) (Copy) (Print) (Backup) (Restore (SC:3)) maintain the keys and create the identification certificates 

(Loan 1 Remaining-Copy-Rights: (Add: Play Print used by the repositories. 

Backup) Next-Set-of-Rights: (Delete: Transfer Loan) When a sending repository transmits a message to a 

(Fee: Metered: $10 Per: 1:0:0 To: Account-ID-567)) receiving repository, the sending repository encrypts all of 

(Loan 1 Remaining-Copy-Rights: Add: ((Play Player: 60 its data using the public writing key of the receiving reposi- 

Player-876-ID) 2 (From: 94/02/14 Until: 95/02/15) (Fee: tory. The sending repository includes its name, the name of 

Metered: $0.01 Pen 0:1:0 Min: $0.25 Per: 0/1/0 To: me receiving repository, a session identifier such as a nonce 

Account-ID-567)))) (described below), and a message counter in each message. 

The original work has rights to Play, Transfer, Copy, Print, In this way, the communication can only be read (to a high 

Backup, Restore, and Loan. There are two versions of the 65 probability) by the receiving repository, which holds the 

Loan right. The first version of the loan right costs $10 per private checking key for decryption. The auxiliary data is 

day but allows the original copy owner to exercise free use used to guard against various replay attacks to security. If 
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messages ever arrive with the wrong counter or an old that they had not previously received. The "hotlists" are 

nonce, the repositories can assume that someone is interfer- maintained and distributed by Master repositories. 

ing with communication and the transaction terminated. Note that rather than terminating in error, the transaction 

The respective public keys for the repositories to be used could request that another registration message be sent based 

for encryption are obtained in the registration transaction 5 on an identification certificate created by another master 

described below. repository. This may be repeated until a satisfactory identi- 

Session Initiation Transactions fication certificate is found, or it is determined that trust 

A usage transaction is carried out in a session between cannot be established, 
repositories. For usage transactions involving more than one Assuming that the repository is not on the hotlist, the 
repository, or for financial transactions between a repository 10 repository identification needs to be verified. In other words, 
and a credit server, a registration transaction is performed. A repository -2 needs to validate that the repository on the other 
second transaction termed a login transaction, may also be end is really repository-1. This is termed performance test- 
needed to initiate the session. The goal of the registration ing and is performed in order to avoid invalid access to the 
transaction is to establish a secure channel between two repository via a counterfeit repository replaying a recording 
repositories who know each other's identities. As it is 15 of a prior session initiation between reposhory-1 and 
assumed that the communication channel between the repository-2. Performance testing is initiated by repository-2 
repositories is reliable but not secure, there is a risk that a generating a performance message, step 1609.. The perfor- 
non-repository may mimic the protocol in order to gain ma nee message consists of a nonce, the names of the 
illegitimate access to a repository. respective repositories, the time and the registration identi- 

The registration transaction between two repositories is 20 fier received from repository-1. A nonce is a generated 

described with respect to FIGS. 16 and 17, The steps message based on some random and variable information 

described are from the perspective of a "repository-1" (e.g. the time or the temperature.) The nonce is used to check 

_ registering its identity with a "repository-2". The registra- whether repository-1 can actually exhibit correct encrypting 

tion must be symmetrical so the same set of steps will be of a message using the private keys it claims to have, on a 

repeated for repository-2 registering its identity with 25 message that it has never seen before. The performance 

repository-1. Referring to FIG. 16, repository-1 first gener- message is encrypted using the public key specified in the 

ates an encrypted registration identifier, step 1601 and then registration message of repository r l. The performance mes- 

generates a registration message, step 1602. A registration sage is transmitted to repository-1, step 1610, where it is 

message is comprised of an identifier of a master repository, decrypted by repository-1 using its private key, step 1611. 

the identification certificate for the repository-1 and an 30 Repository-1 then checks to make sure that the names of the 

encrypted random registration identifier. The identification two repositories are correct, step 1612, that the time is 

certificate is encrypted by the master repository in its private accurate, step 1613 and that the registration identifier cor- 

key and attests to the fact that the repository (here responds to the one it sent, step 1614. If any of these tests 

repository-1) is a bona fide repository. The identification fails, the transaction is terminated per step 1616. Assuming 

certificate also contains a public key for the repository, the 35 that the tests are passed, repository-1 transmits the nonce to 

repository security level and a timestamp (indicating a time repository-2 in the clear, step 1615. Repository-2 then 

after which the certificate is no longer valid.) The registra- compares the received nonce to the original nonce, step 

tion identifier is a number generated by the repository for 1617. If they are not identical, the registration transaction 

this registration. The registration identifier is unique to the terminates in an error per step 1618. If they are the same, the 

session and is encrypted in repository-1 's private key. The 40 registration transaction has successfully completed, 

registration identifier is used to improve security of authen- At this point, assuming that the transaction has not 

tication by detecting certain kinds of communications based terminated, the repositories exchange messages containing 

attacks. Repository-1 then transmits the registration message session keys to be used in all communications during the 

to repository-2, step 1603. session and synchronize their clocks. FIG. 17 illustrates the 

Upon receiving the registration message, repository-2 45 session information exchange and clock synchronization 

determines if it has the needed public key for the master steps (again from the perspective of repository-1.) Referring 

repository, step 1604. If repository-2 does not have the to FIG. 17, repository-1 creates a session key pair, step 1701. 

needed public key to decrypt the identification certificate, A first key is kept private and is used by repository-1 to 

the registration transaction terminates in an error, step 1618. encrypt messages. The second key is a public key used by 

Assuming that repository-2 has the proper public key the 50 repository-2 to decrypt messages. The second key is 

identification certificate is decrypted, step 1605. encrypted using the public key of repository-2, step 1702 

Repository-2 saves the encrypted registration identifier, step and is sent to repository-2, step 1703. Upon receipt, 

1606, and extracts the repository identifier, step 1607. The repository-2 decrypts the second key, step 1704. The second 

extracted repository identifier is checked against a "hotlist" key is used to decrypt messages in subsequent communica- 

of compromised document repositories, step 1608. In the 55 tions. When each repository has completed this step, they are 

currently preferred embodiment, each repository will con- both convinced that the other repository is bona fide and that 

tain "hotlists" of compromised repositories. If the repository they are communicating with the original. Each repository 

is on the "hotlist*, the registration transaction terminates in has given the other a key to be used in decrypting further 

an error per step 1618. Repositories can be removed from communications during the session. Since that key is itself 

the hotlist when their certificates expire, so that the list does 60 transmitted in the public key of the receiving repository only 

not need to grow without bound. Also, by keeping a short list it will be able to decrypt the key which is used to decrypt 

of hotlist certificates that it has previously received, a subsequent messages. 

repository can avoid the work of actually going through the After the session information is exchanged, the reposito- 

list. These lists would be encrypted by a master repository. ries must synchronize their clocks. Clock synchronization is 

A minor variation on the approach to improve efficiency 65 used by the repositories to establish an agreed upon time 

would have the repositories first exchange lists of names of base for the financial records of their mutual transactions, 

hotlist certificates, ultimately exchanging only those lists Referring back to FIG. 17, repository-2 initiates clock 
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synchronization by generating a time stamp exchange would exchange periodic charge information for each 

message, step 1705, and transmits it to repository-1, step block of time.) 

1706. Upon receipt, repository-1 generates its own time A report-charges transaction between a personal credit 

stamp message, step 1707 and transmits it back to server and a billing clearinghouse. This transaction is 

repository-2, step 1708. Repository-2 notes the current time, 5 invoked at least once per billing period. It is used to 

step 1709 and stores the time received from repository-1, pass along information about charges. On debit and 

step 1710, The current time is compared to the time received credit cards, this transaction would also be used to 

from repository-1, step 1711. The difference is then checked update balance information and credit limits as needed, 

to see if it exceeds a predetermined tolerance (e.g. one All billing transactions are given a transaction ID and are 

minute), step 1712. If it does, repository-2 terminates the 10 reported to the credit severs by both the server and the client, 

transaction as this may indicate tampering with the This reduces possible loss of billing information if one of the 

repository, step 1713. If not repository-2 computes an parties to a transaction loses a banking card and provides a 

adjusted time delta, step 1714. The adjusted time delta is the check against tampering with the system, 

difference between the clock time of repository-2 and the Usage Transactions 

average of the times from repository-1 and repository-2. 35 After the session initiation transactions have been 

To achieve greater accuracy, repository-2 can request the completed, the usage request may then be processed. To 

time again up to a fixed number of times (e.g. five times), simplify the description of the steps carried out in processing 

repeat the clock synchronization steps, and average the a usage request, the term requester is used to refer to a 

results. repository in the requester mode which is initiating a 

A second session initiation transaction is a Login trans- 20 request, and the term server is used to refer to a repository 

action. The Login transaction is used to check the authen- in the server mode and which contains the desired digital 

ticity of a user requesting a transaction. A Login transaction work. In many cases such as requests to print or view a work, 

is particularly prudent for the authorization of financial the requester and server may be the same device and the 

transactions that will be charged to a credit server. The Login transactions described in the following would be entirely 

transaction involves an interaction between the user at a user 25 internal. In such instances, certain transaction steps, such as 

interface and the credit server associated with a repository. the registration transaction, need not be performed. 

The information exchanged here is a login string supplied by There are some common steps that are part of the seman- 

the repository/credit server to identify itself to the user, and tics of all of the usage rights transactions. These steps are 

a Personal Identification Number (PIN) provided by the user referred to as the common transaction steps. There are two 

to identify himself to the credit server. In the event that the 30 sets — the "opening" steps and the "closing" steps. For 

user is accessing a credit server on a repository different simplicity, these are listed here rather than repeating them in 

from the one on which the user interface resides, exchange the descriptions of all of the usage rights transactions, 

of the information would be encrypted using the public and Transactions can refer to a part of a digital work, a 

private keys of the respective repositories. complete digital work, or a Digital work containing other 

Billing Transactions 35 digital works. Although not described in detail herein, a 

Billing Transactions are concerned with monetary trans- transaction may even refer to a folder comprised of a 

action with a credit server. Billing Transaction are carried plurality of digital works. The term "work" is used to refer 

out when all other conditions are satisfied and a usage fee is to what ever portion or set of digital works is being accessed, 

required for granting the request. For the most part, billing Many of the steps here involve determining if certain 

transactions are well understood in the state of the art. These 40 conditions are satisfied Recall that each usage right may 

transactions are between a repository and a credit server, or have one or more conditions which must be satisfied before 

between a credit server and a billing clearinghouse. Briefly, the right can be exercised. Digital works have parts and parts 

the required transactions include the following: have parts. Different parts can have different rights and fees. 

Registration and LOGIN transactions by which the Thus, it is necessary to verify that the requirements are met 

repository and user establish their bona fides to a credit 45 f° r ALL of the parts that are involved in a transaction For 

server. These transactions would be entirely internal in brevity, when reference is made to checking whether the 

cases where the repository and credit server are imple- rights exist and conditions for exercising are satisfied, it is 

mented as a single system. meant that all such checking takes place for each of the 

Registration and LOGIN transactions, by which a credit relevant parts of the work, 

server establishes its bona fides to a billing clearing- 50 nG - 18 Jlustrates . me mitia l common opening and closing 

house. steps for a transaction. At this point it is assumed that 

AA . r . 4 . 4 , ,., . . registration has occurred and mat a "trusted" session is in 

An Assign-fee transaction to assign a charge. The infer- , ~ ^ , t t , , - . 4 . t , ... 

4 . fr - , j place. General tests are tests on usage rights associated with 

mation in this transaction would include a transaction ,l f)J . ■ . , 4 . . r . , 

■-j .u -j r ^ » » . . the folder containing the work or some containing folder 

identifier, the identities of the repositories in the ....... fil ' & . ™ . 4 B . 

. .. . , . «_ ... ^ r 4 u 55 higher in the file system hierarchy. These tests correspond to 

transaction, and a list of charges from the parts of the • ' A *u i # ■« 

j- ■. i \ if.u . , , . • iL requirements imposed on the work as a consequence of its 

digital work. If there has been any unusual event in the . . ,. v.. , .. M . . . . 

transaction such as an interruption of communications, 1?,^ parU f.* r J^I 01 * » to ^ 

that information is included as well. **** 10 the work ltself - 10 HG - P nor t0 

iuauuu » uiwuu«i wcu. initiating a usage transaction, the requester performs any 

An Begin<harges transaction to assign a charge. This 60 general tests that are required before the right associated 

transaction is much the same as an assign-fee transac- with the transaction can be exercised, step, 1801. For 

tion except that it is used for metered use. It includes example, install, uninstaU and delete rights may be imple- 

the same information as the assign-fee transaction as mentcd t0 require ^ a requester have an authorization 

well as the usage fee information. The credit-server is certificate before the right can be exercised. Another 

then responsible for running a clock. 65 examp i 6 ^ the requirement that a digital ticket be present 

An End-charges transaction to end a charge for metered and punched before a digital work may be copied to a 

use. (In a variation on this approach, the repositories requester. If any of the general tests fail, the transaction is 
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not initiated, step, 1802. Assuming that such required tests 
are passed, upon receiving the usage request, the server 
generates a transaction identifier that is used in records or 
reports of the transaction, step 1803. The server then checks 
whether the digital work has been granted the right corre- 
sponding to the requested transaction, step 1804. If the 
digital work has not been granted the right corresponding to 
the request, the transaction terminates, step 1805. If the 
digital work has been granted the requested right, the server 
then determines if the various conditions for exercising the 
right are satisfied. Time based conditions are examined, step 
1806. These conditions are checked by examining the time 
specification for the the version of the right. If any of the 
conditions are not satisfied, the transaction terminates per 
step 1805. 

Assuming that the time based conditions are satisfied, the 
server checks security and access conditions, step 1807. 
Such security and access conditions are satisfied if: 1) the 
requester is at the specified security class, or a higher 
security class, 2) the server satisfies any specified authori- 
zation test and 3) the requester satisfies any specified autho- 
rization tests and has any required digital tickets. If any of 
the conditions are not satisfied, the transaction terminates 
per step 1805. 

Assuming that the security and access conditions are all 
satisfied, the server checks the copy count condition, step 
1808. If the copy count equals zero, then the transaction 
cannot be completed and the transaction terminates per step 
1805. 

Assuming that the copy count does not equal zero, the 
server checks if the copies in use for the requested right is 
greater than or equal to any copy count for the requested 
right (or relevant parts), step 1809. If the copies in use is 
greater than or equal to the copy count, this indicates that 
usage rights for the version of the transaction have been 35 
exhausted. Accordingly, the server terminates the 
transaction, step 1805. If the copy count is less than the 
copies in use for the transaction the transaction can continue, 
and the copies in use would be incremented by the number 
of digital works requested in the transaction, step 1810. 

The server then checks if the digital work has a "Loan" 
access right, step 1811. The "Loan" access right is a special 
case since remaining rights may be present even though all 
copies are loaned out. If the digital work has the "Loan" 
access right, a check is made to see if all copies have been 
loaned out, step 1812. The number of copies that could be 
loaned is the sum of the Copy-Counts for all of the versions 
of the loan right of the digital work. For a composite work, 
the relevant figure is the minimal such sum of each of the 
components of the composite work. If all copies have been 
loaned out, the remaining rights are determined, step 1813. 
The remaining-rights is determined from the remaining 
rights specifications from the versions of the Loan right. If 
there is only one version of the Loan right, then the 



then checked, step 1815. This will initiate various financial 
transactions between the repository and associated credit 
server. Further, any metering of usage of a digital work will 
commence. If any financial transaction fails, the transaction 
terminates per step 1805. 

It should be noted that the order in which the conditions 
are checked need not follow the order of steps 1806-1815. 

At this point, right specific steps are now performed and 
are represented here as step 1816. The right specific steps are 
described in greater detail below. 

The common closing transaction steps are now per- 
formed. Each of the closing transaction steps are performed 
by the server after a successful completion of a transaction. 
Referring back to FIG. 18, the copies in use value for the 
requested right is decremented by the number of copies 
involved in the transaction, step 1817. Next, if the right had 
a metered usage fee specification, the server subtracts the 
elapsed time from the Remammg-Use-Time associated with 
the right for every part involved in the transaction, step 
1818. Finally, if there are fee specifications associated with 
the right, the server initiates End-Charge financial transac- 
tion to confirm billing, step 1819. 
Transmission Protocol 

An important area to consider is the transmission of the 
digital work from the server to the requester. The transmis- 
sion protocol described herein refers to events occurring 
after a valid session has been created. The transmission 
protocol must handle the case of disruption in the commu- 
nications between the repositories. It is assumed that inter- 
ference such as injecting noise on the communication chan- 
nel can be detected by the integrity checks (e.g., parity, 
checksum, etc.) that are built into the transport protocol and 
are not discussed in detail herein. 

The underlying goal in the transmission protocol is to 
preclude certain failure modes, such as malicious or acci- 
dental interference on the communications channel. 
Suppose, for example, that a user pulls a card with the credit 
server at a specific time near the end of a transaction. There 
should not be a vulnerable time at which "pulling the card" 
40 causes the repositories to fail to correctly account for the 
number of copies of the work that have been created. 
Restated, there should be no time at which a party can break 
a connection as a means to avoid payment after using a 
digital work. 

If a transaction is interrupted (and fails), both repositories 
restore the digital works and accounts to their state prior to 
the failure, modulo records of the failure itself. 

FIG. 19 is a state diagram showing steps in the process of 
transmitting information during a transaction. Each box 
represents a state of a repository in either the server mode 
(above the central dotted line 1901 ) or in the requester mode 
(below the dotted line 1901). Solid arrows stand for transi- 
tions between states. Dashed arrows stand for message 
communications between the repositories. A dashed mes- 
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determination is simple. The remaining rights are the ones 55 sage arrow pointing to a solid transition arrow is interpreted 



specified in that version of the Loan right, or none if 
Remaining-Rights: is not specified. If there are multiple 
versions of the Loan right and all copies of all of the versions 
are loaned out, then the remaining rights is taken as the 
minimum set (intersection) of remaining rights across all of 60 
the versions of the loan right. The server then determines if 
the requested right is in the set of remaining rights, step 
1814. If the requested right is not in the set of remaining 
rights, the server terminates the transaction, step 1805. 

If Loan is not a usage right for the digital work or if all 65 
copies have not been loaned out or the requested right is in 
the set of remaining rights, fee conditions for the right are 



as meaning that the transition takes place when the message 
is received. Unlabeled transition arrows take place uncon- 
ditionally. Other labels on state transition arrows describe 
conditions that trigger the transition. 

Referring now to FIG. 19, the server is initially in a state 
1902 where a new transaction is initiated via start message 
1903. This message includes transaction information includ- 
ing a transaction identifier and a count of the blocks of data 
to be transferred. The requester, initially in a wait state 1904 
then enters a data wait state 1905. 

The server enters a data transmit state 1906 and transmits 
a block of data 1907 and then enters a wait for acknowl- 
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edgement state 1908. As the data is received, the requesters The requester may have received all of the data, but if it did 

enters a data receive state 1909 and when the data blocks is not get the final message, it has not committed. The server 

completely received it enters an acknowledgement state can go ahead and delete files (except for transaction records) 

1910 and transmits an Acknowledgement message 1911 to once il commits, since the files are known to have been fully 

the server. 5 transmitted before starting the 2PC cycle. 

If there are more blocks to send, the server waits until T^ 16 are variations known in the art which can be used 
receiving an Acknowledgement message from the requester. to achieve the same effect. For example, the server could use 
When an Acknowledgement message is received it sends the an «ddu*raal level of encryption when transmitting a work 
next block to the requester and again waits for acknowl- *°, a . chcnt * 9°^ ^ chent sends a message acknowl- 
edgement. The requester also repeats the same cycle of 10 ed ^ ™ c f do f s 11 ***** k ?> [ ^ ;dicnt then agrees to 
states pay for the digital work. The point of this vanation is that it 

T , ' . . . . A . c .. , r provides a clear audit trail that the client received the work. 

If the server detects a communications failure before Fof hQ ^ fldds a ^ q[ 

sending the last block, it enters a cancellation state 1912 encryption for no real gain ^ accountabQity. 

wherein the transaction is cancelled. Similarly, if the ^ transaction for specific usage rights are now dis- 

requester detects a communications failure before receiving is cusse( j. 

the last block it enters a cancellation state 1913. Th e Qjpy Transaction 

If there are no more blocks to send, the server commits to a Copy transaction is a request to make one or more 

the transaction and waits for the final Acknowledgement in independent copies of the work with the same or lesser usage 

state 1914. If there is a communications failure before the rights. Copy differs from the extraction right discussed later 

server receives the final Acknowledgement message, it still 20 in that it refers to entire digital works or entire folders 

commits to the transaction but includes a report about the containing digital works. A copy operation cannot be used to 

event to its credit server in state 1915. This report serves two remove a portion of a digital work, 

purposes. It will help legitimize any claims by a user of The requester sends the server a message to initiate the Copy 

having been billed for receiving digital works that were not Transaction. This message indicates the work to be 

completely received. Also it helps to identify repositories 25 copied, the version of the copy right to be used for the 

and communications lines that have suspicious patterns of transaction, the destination address information (location 

use and interruption. The server then enters its completion in a folder) for placing the work, the file data for the work 

state 1916. (including its size), and the number of copies requested. 

On the requester side, when there are no more blocks to The repositories perform the common opening transaction 

receive, the requester commits to the transaction in state 30 steps. 

1917. If the requester detects a communications failure at The server transmits the requested contents and data to the 
this state, it reports the failure to its credit server in state client according to the transmission protocol. If a Next- 

1918, but still commits to the transaction. When it has Set-Of-Rights has been provided in the version of the 
committed, it sends an acknowledgement message to the right, those rights are transmitted as the rights for the 
server. The server then enters its completion state 1919. 35 work. Otherwise, the rights of the original are transmitted. 

The key property is that both the server and the requester In any event, the Copy-Count field for the copy of the 

cancel a transaction if it is interrupted before all of the data digital work being sent right is set to the number-of-copies 

blocks are delivered, and commits to it if all of the data requested. 

blocks have been delivered. The requester records the work contents, data, and usage 

There is a possibility that the server will have sent all of 40 rights and stores the work. It records the date and time that 

the data blocks (and committed) but the requester will not the copy was made in the properties of the digital work, 

have received all of them and will cancel the transaction. In The repositories perform the common closing transaction 

this case, both repositories will presumably detect a com- steps, 

munications failure and report it to their credit server. This The Transfer Transaction 

case will probably be rare since it depends on very precise 45 A Transfer transaction is a request to move copies of the 

timing of the communications failure. The only consequence work with the same or lesser usage rights to another reposi- 

will be that the user at the requester repository may want to tory. In contrast with a copy transaction, this results in 

request a refund from the credit services — and the case for removing the work copies from the server, 

that refund will be documented by reports by both reposi- The requester sends the server a message to initiate the 

tories. 50 Transfer Transaction. This message indicates the work to 

To prevent loss of data, the server should not delete any be transferred, the version of the transfer right to be used 

transferred digital work until receiving the final acknowl- in the transaction, the destination address information for 

edgement from the requester. But it also should not use the placing the work, the file data for the work, and the 

file. A well known way to deal with this situation is called number of copies involved. 

"two-phase commit" or 2 PC. 55 The repositories perform the common opening transaction 

Two-phase commit works as follows. The first phase steps, 

works the same as the method described above. The server The server transmits the requested contents and data to the 

sends all of the data to the requester. Both repositories mark requester according to the transmission protocol. If a 

the transaction (and appropriate files) as uncommitted. The Next-Set-Of-Rights has been provided, those rights are 

server sends a ready-to-commit message to the requester. 60 transmitted as the rights for the work. Otherwise, the 

The requester sends back an acknowledgement. The server rights of the original are transmitted. In either case, the 

then commits and sends the requester a commit message. Copy-Count field for the transmitted rights are set to the 

When the requester receives the commit message, it com- number-of-copies requested. 

mits the file. The requester records the work contents, data, and usage 

If there is a communication failure or other crash, the 65 rights and stores the work, 

requester must check back with the server to determine the The server decrements its copy count by the number of 

status of the transaction. The server has the last word on this. copies involved in the transaction. 
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The repositories perform the common closing transaction through some kind of transducer, such as a speaker or a 

steps. display device. The request implies the intention that the 

If the number of copies remaining in the server is now zero, contents will not be communicated digitally to any other 

it erases the digital work from its memory. system. For example, they will not be sent to a printer, 

The Loan Transaction 5 recorded on any digital medium, retained after the transac- 

A loan transaction is a mechanism for loaning copies of a ^ or ^ t0 repository, 

digital work. The maximum duration of the loan is deter- term fa . natural for examp les like playing 

mined by an internal parameter of the digital work Works musi j ^ a movi Qr , a { a ^ ^ 

are ^automatically returned after a predetermined time general form of play means tha\ a "pllyer" is used to use the 

^requester sends the server a message to initiate the 30 ^ work. However^ the term play covers afl media and 

Transfer Transaction. This message indicates the work to bnds . of recordin f ■ ™» one w ° uld W a d ^ tal work . 

be loaned, the version of the loan right to be used in the meamn S, to render it for reading, or play a computer 

transaction, the destination address information for plac- P ™^^ZTbHdi i5 t'a t * 

ing the work, the number of copies involved, the file data PJ 1 ° 6 j IF 3 ' C a ^ en "... . , 

for the work, and the period of the loan. 15 ™, e ^ nds *** se™ a message to initiate the play 

tu u 1 .i. i-j'. *.u . ji - -i transaction. This message indicates the work to be played, 

The server checks the validity of the requested loan period, iL . „ . , B . , . . , v } . ' 

and ends with an error if the period is not valid. Loans for J° V f ^ of * e P 1 ^ "*? Uo be ™ d » * e ?f 

a loaned copy cannot extend beyond the period of the £ of the P la y er bem S ^ and tbe me for 

Tk!"™!'-!!!-!.. 1 -i!^™^- ~ ■ . 20 The server checks the validity of the player identification 

The repositories perform the common opemng transaction , t ...... *. u * I :-n ... 

ste g r r b and compatibdity of the player identification with the 

The server transmits the requested contents and data to the $*ya specification in the right. It ends with an error if 

requester. If a Next-Set-Of-Rights has been provided, < hcsc not sat ^ factor y- . 

those rights are transmitted as the rights for the work. ^ repositories perform the common opening transaction 

Otherwise, the rights of the original are transmitted, as 25 * eps ' , , rj 

modified to reflect the loan period. ™ e 8CTVCr read 30(1 wnte ^ blocks of data 45 

The requester records the digital work contents, data, usage requested by the player according to the transmission 

rights, and loan period and stores the work. P[ otoco1 - ^ r ^ uester P la * s work contents ' ^ the 

The server updates the usage rights information in the digital „J? ay f5' , . a . . . t . . . , 

work to reflect the number of copies loaned out. 30 ^ me ^ 15 fin f hed ' * e P la y er and me re£ » uester 

The repositories perform the common closing transaction ' emOVe the from mem °7" . 

sle p^ r The repositories perform the common closing transaction 

The server updates the usage rights data for the digital work. t^^^' T 

This may preclude use of the work until it is returned from 1 ™ A ™* lransac f 10n , 

the loan. The user on the requester platform can now use 35 * a to obtain the cootente of a 

the transferred copies of the digital work. Auser accessing WOrk for ^P^se of rendering them on a "printer. We 

the original repository cannot use the digital work , unless us * k the } crm P nnt< £ to mclude tbe 00111111011 « of 

there are copies remaining. What happens next depends Wlth ^ However " ke * "P** ° f P naU f * ? 

on the order of events in time. our ^ of term 18 that 11 makes a of tne dl S ltal work 

Case 1. If the time of the loan period is not yet exhausted 40 l " a P laCe ° ulside of lhe P™ 1 ^™ ° f »"f A» w Jh 

and the requester sends the repository a Return message. 'J^* P arUcular authonzatlon ^rt^* 

The return message includes the requester identification, rt ' „ A . , , . . , . .... . 

and the transaction ID digital work is printed, the publisher and user are 
_ , ' . . bound by whatever copyright laws are in effect. However, 
The server decrements the copies-in-use field by the 45 printing moves the contents outside the control of reposito- 
number of copies that were returned. (If the number of ries For cxamp i e> abseot any otncr cnforcemeD t 
digital works returned is greater than the number acta- mecha nisms, once a digital work is printed on paper, it can 
ally borrowed, this is treated as an error.) This step may be ied on ordin photocopying machines without inter- 
now make the work available at the server for other vention by a KpositOT y l0 coUect usage fees. If the printer to 

users " 50 a digital disk is permitted, then that digital copy is outside 

The requester deactivates its copies and removes the o£ me co^ of righls Both tne creator and the ^ 

contents from its memory. mis> although the creator does not necessarily give 

Case 2. If the time of the loan period is exhausted and the tacit consent to such copying, which may violate copyright 

requester has not yet sent a Return message. [ awS- 

The server decrements the copies-in-use field by the ss The requester sends the server a message to initiate a Print 

number digital works that were borrowed. transaction. This message indicates the work to be played, 

The requester automatically deactivates its copies of the the identity of the printer being used, the file data for the 

digital work. It terminates all current uses and erases work, and the number of copies in the request. 

the digital work copies from memory. One question is The server checks the validity of the printer identification 

why a requester would ever return a work earlier than 60 and the compatibility of the printer identification with the 

the period of the loan, since it would be returned printer specification in the right. It ends with an error if 

automatically anyway. One reason for early return is these are not satisfactory. 

that there may be a metered fee which determines the The repositories perform the common opening transaction 

cost of the loan. Returning early may reduce that fee. steps. 

The Play Transaction 65 Tbe server transmits blocks of data according to the trans- 

A play transaction is a request to use the contents of a mission protocol 

work. Typically, to "play" a work is to send the digital work The requester prints the work contents, using the printer. 
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When the printer is finished, the printer and the requester The server verifies that the contents file is available (i.e. a 

remove the contents from their memory. digital work corresponding to the request has been 

The repositories perform the common closing transaction backed-up.) If it is not, it ends the transaction with an 

steps. error. 

The Backup Transaction 5 The repositories perform the common opening transaction 

A Backup transaction is a request to make a backup copy steps, 

of a digital work, as a protection against media failure. In the ^ xr , eT ret rieves the key from the restoration file. It 

context of repositories, secure backup copies differ from d te ^ work contems ^ uaagc rights . 

other copies in three ways: (1) they are made under the ^ ^ transmils ^ ted ^ dat& tQ ^ 

control of a Backup transaction rather than a Copy ^ aocordin J transmission protocol. If a 

transaction, (2) they do not count as regular copies, and (3) J? 1 t 0 t rtr n . & . , . * . . t 

they are not usable as regular copies Generally, backup Next-Set-Of-Rights has been provide^ those rights are 

copies are encrypted. transmitted as the rights for the work. Otherwise, a set of 

Although backup copies may be transferred or copied, default nghts for backup files of the original are trans- 
depending on their assigned rights, the only way to make mittcd by the server, 
them useful for playing, printing or embedding is to restore 15 The requester stores the digital work. 
t nem . The repositories perform the common closing transaction 

The output of a Backup operation is both an encrypted steps, 

data file that contains the contents and description of a work, The Delete Transaction 

and a restoration file with an encryption key for restoring the A Delete transaction deletes a digital work or a number of 

encrypted contents. In many cases, the encrypted data file 20 copies of a digital work from a repository. Practically all 

would have rights for "printing" it to a disk outside of the digital works would have delete rights, 

protection system, relying just on its encryption for security. The requester sends the server a message to initiate a delete 

Such files could be stored anywhere that was physically safe transaction. This message indicates the work to be 

and convenient. The restoration file would be held in the deleted, the version of the delete right for the transaction, 

repository. This file is necessary for the restoration of a 25 The repositories perform the common opening transaction 

backup copy. It may have rights for transfer between reposi- steps. 

tories. The server deletes the file, erasing it from the file system. 

The requester sends the server a message to initiate a backup The repositories perform the common closing transaction 

transaction. This message indicates the work to be backed steps. 

up, the version of the backup right to be used in the 30 The Directory Transaction 

transaction, the destination address information for plac- A Directory transaction is a request for information about 

ing the backup copy, the file data for the work. folders, digital works, and their parts. This amounts to 

The repositories perform the common opening transaction roughly the same idea as protection codes in a conventional 

steps. file system like TENEX, except that it is generalized to the 

The server transmits the requested contents and data to the 35 full power of the access specifications of the usage rights 

requester. If a Next-Set-Of-Rights has been provided, language. 

those rights are transmitted as the rights for the work. The Directory transaction has the important role of pass- 
Otherwise, a set of default rights for backup files of the ing along descriptions of the rights and fees associated with 
original are transmitted by the server. a digital work. When a user wants to exercise a right, the 
The requester records the work contents, data, and usage 40 user interface of his repository implicitly makes a directory 
rights. It then creates a one-time key and encrypts the request to determine the versions of the right that are 
contents file. It saves the key information in a restoration available. Typically these are presented to the user — such as 
file. with different choices of billing for exercising a right. Thus, 
The repositories perform the common closing transaction many directory transactions are invisible to the user and are 
steps. 45 exercised as part of the normal process of exercising all 
In some cases, it is convenient to be able to archive the rights, 
large, encrypted contents file to secure online storage, such The requester sends the server a message to initiate a 
as a magneto-optical storage system or magnetic tape. This Directory transaction. This message indicates the file or 
creation of a non-repository archive file is as secure as the folder that is the root of the directory request and the 
encryption process. Such non-repository archive storage is 50 version of the directory right used for the transaction, 
considered a form of "printing" and is controlled by a print The server verifies that the information is accessible to the 
right with a specified "archive-printer." An archive-printer requester. In particular, it does not return the names of any 
device is programmed to save the encrypted contents file files that have a HIDE-NAME status in their directory 
(but not the description file) offline in such a way that it can specifications, and it does not return the parts of any 
be retrieved. 55 folders or files that have HIDE-PARTS in their specifi- 
The Restore Transaction cation. If the information is not accessible, the server ends 

A Restore transaction is a request to convert an encrypted the transaction with an error, 

backup copy of a digital work into a usable copy. A restore The repositories perform the common opening transaction 

operation is intended to be used to compensate for cata- steps. 

strophic media failure. Like all usage rights, restoration 60 The server sends the requested data to the requester accord- 
rights can include fees and access tests including authori- ing to the transmission protocol, 
zation checks. The requester records the data. 

The requester sends the server a message to initiate a Restore The repositories perform the common closing transaction 

transaction. This message indicates the work to be steps, 

restored, the version of the restore right for the 65 The Folder Transaction 

transaction, the destination address information for plac- A Folder transaction is a request to create or rename a 

ing the work, and the file data for the work. folder, or to move a work between folders. Together with 
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Directory rights, Folder rights control the degree to which 
organization of a repository can be accessed or modified 
from another repository. 

The requester sends the server a message to initiate a Folder 
transaction. This message indicates the folder that is the 
root of the folder request, the version of the folder right 
for the transaction, an operation, and data. The operation 
can be one of create, rename, and move file. The data are 
the specifications required for the operation, such as a 
specification of a folder or digital work and a name. 

The repositories perform the common opening transaction 
steps. 

The server performs the requested operation — creating a 
folder, renaming a folder, or moving a work between 
folders. 

The repositories perform the common closing transaction 
steps. 

The Extract Transaction 

A extract transaction is a request to copy a part of a digital 
work and to create a new work containing it. The extraction 
operation differs from copying in that it can be used to 
separate a part of a digital work from d-blocks or shells that 
place additional restrictions or fees on it. The extraction 
operation differs from the edit operation in that it does not 
change the contents of a work, only its embedding in 
d-blocks. Extraction creates a new digital work. 
The requester sends the server a message to initiate an 
Extract transaction. This message indicates the part of the 
work to be extracted, the version of the extract right to be 
used in the transaction, the destination address informa- 
tion for placing the part as a new work, the file data for 
the work, and the number of copies involved. 
The repositories perform the common opening transaction 
steps. 

The server transmits the requested contents and data to the 
requester according to the transmission protocol. If a 
Next-Set-Of-Rights has been provided, those rights are 
transmitted as the rights for the new work. Otherwise, the 
rights of the original are transmitted. The Copy-Count 
field for this right is set to the number-of-copies 40 
requested. 

The requester records the contents, data, and usage rights 
and stores the work. It records the date and time that new 
work was made in the properties of the work. 

The repositories perform the common closing transaction 45 
steps. 

The Embed Transaction 

An embed transaction is a request to make a digital work 
become a part of another digital work or to add a shell 
d-block to enable the adding of fees by a distributor of the 
work. 

The requester sends the server a message to initiate an 
Embed transaction. This message indicates the work to be 
embedded, the version of the embed right to be used in the 
transaction, the destination address information for plac- 
ing the part as a a work, the file data for the work, and the 
number of copies involved. 

The server checks the control specifications for all of the 
rights in the part and the destination. If they are 
incompatible, the server ends the transaction with an 
error. 

The repositories perform the common opening transaction 
steps. 

The server transmits the requested contents and data to the 
requester according to the transmission protocol. If a 
Next-Set-Of-Rights has been provided, those rights are 
transmitted as the rights for the new work. Otherwise, the 
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rights of the original are transmitted. The Copy-Count 
field for this right is set to the number-of-copies 
requested. 

The requester records the contents, data, and usage rights 

and embeds the work in the destination file. 
The repositories perform the common closing transaction 

steps. 
The Edit Transaction 

An Edit transaction is a request to revise a digital work by 
copying, selecting and modifying portions of an existing 
digital work. This operation can actually change the contents 
of a digital work. The kinds of changes that are permitted 
depend on the process being used. Like the extraction 
operation, edit operates on portions of a digital work. In 
contrast with the extract operation, edit does not effect the 
rights or location of the work. It only changes the contents. 
The kinds of changes permitted are determined by the type 
specification of the processor specified in the rights. In the 
currently preferred embodiment, an edit transaction changes 
the work itself and does not make a new work. However, it 
would be a reasonable variation to cause a new copy of the 
work to be made. 

The requester sends the server a message to initiate an Edit 
transaction. This message indicates the work to be edited, 
the version of the edit right to be used in the transaction, 
the file data for the work (including its size), the process- 
ID for the process, and the number of copies involved. 

The server checks the compatibility of the process-ID to be 
used by the requester against any process-ID specification 
in the right. If they are incompatible, it ends the transac- 
tion with an error. 

The repositories perform the common opening transaction 
steps. 

The requester uses the process to change the contents of the 
digital work as desired. (For example, it can select and 
duplicate parts of it; combine it with other information; or 
compute functions based on the information. This can 
amount to editing text, music, or pictures or taking 
whatever other steps are useful in creating a derivative 
work.) 

The repositories perform the common closing transaction 
steps. 

The edit transaction is used to cover a wide range of kinds 
of works. The category describes a process that takes as its 
input any portion of a digital work and then modifies the 
input in some way. For example, for text, a process for 
editing the text would require edit rights. A process for 
"summarizing" or counting words in the text would also be 
considered editing. For a music file, processing could 
involve changing the pitch or tempo, or adding 
reverberations, or any other audio effect. For digital video 
works, anything which alters the image would require edit 
rights. Examples would be colorizing, scaling, extracting 
still photos, selecting and combining frames into story 
boards, sharpening with signal processing, and so on. 

Some creators may want to protect the authenticity of 
their works by limiting the kinds of processes that can be 
performed on them. If there arc no edit rights, then no 
processing is allowed at all. A processor identifier can be 
included to specify what kind of process is allowed. If no 
process identifier is specified, then arbitrary processors can 
be used. For an example of a specific process, a photogra- 
pher may want to allow use of his photograph but may not 
want it to be colorized. A musician may want to allow 
extraction of portions of his work but not changing of the 
tonality. 
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Authorization Transactions 

There are many ways that authorization transactions can 
be defined. In the following, our preferred way is to simply 
define them in terms of other transactions that we already 
need for repositories. Thus, it is convenient sometimes to 
speak of "authorization transactions," but they are actually 
made up of other transactions that repositories already have. 

A usage right can specify an autborizatioa-ED, which 
identifies an authorization object (a digital work in a file of 
a standard format) that the repository must have and which 
it must process. The authorization is given to the generic 
authorization (or ticket) server of the repository which 
begins to interpret the authorization. 

As described earlier, the authorization contains a server 
identifier, which may just be the generic authorization server 
or it may be another server. When a remote authorization 
server is required, it must contain a digital address. It may 
also contain a digital certificate. 

If a remote authorization server is required, then the 
authorization process first performs the following steps: 
The generic authorization server attempts to set up the 
communications channel. (If the channel cannot be set 
up, then authorization fails with an error.) 
When the channel is set up, it performs a registration 
process with the remote repository. (If registration fails, 
then the authorization fails with an error.) 
When registration is complete, the generic authorization 
server invokes a "Play" transaction with the remote 
repository, supplying the authorization document as the 
digital work to be played, and the remote authorization 
server (a program) as the "player." (If the player cannot 
be found or has some other error, then the authorization 
fails with an error.) 
The authorization server then "plays" the authorization. 
This involves decrypting it using either the public key 
of the master repository that issued the certificate or the 
session key from the repository that transmitted it. The 
authorization server then performs various tests. These 
tests vary according to the authorization server. They 
include such steps as checking issue and validity dates 
of the authorization and checking any hot-lists of 
known invalid authorizations. The authorization server 
may require carrying out any other transactions on the 
repository as well, such as checking directories, getting 
some person to supply a password, or playing some 
other digital work. It may also invoke some special 
process for checking information about locations or 
recent events. The "script" for such steps is contained 
within the authorization server. 
If all of the required steps are completed satisfactorily, the 
authorization server completes the transaction 
normally, signaling that authorization is granted. 
The Install Transaction 

An Install transaction is a request to install a digital work 
as runnable software on a repository. In a typical case, the 
requester repository is a rendering repository and the soft- 
ware would.be a new kind or new version of a player. Also 
in a typical case, the software would be copied to file system 
of the requester repository before it is installed. 
The requester sends the server an Install message. This 
message indicates the work to be installed, the version of 
the Install right being invoked, and the file data for the 
work (including its size). 
The repositories perform the common opening transaction 
steps. 

The requester extracts a copy of the digital certificate for the 
software. If the certificate cannot be found or the master 
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repository for the certificate is not known to the requester, 
the transaction ends with an error. 
The requester decrypts the digital certificate using the public 
key of the master repository, recording the identity of the 
supplier and creator, a key for decrypting the software, the 
compatibility information, and a tamper-checking code. 
(This step certifies the software.) 
The requester decrypts the software using the key from the 
certificate and computes a check code on it using a 1-way 
hash function. If the check-code does not match the 
tamper-checking code from the certificate, the installation 
transaction ends with an error. (This step assures that the 
contents of the software, including the various scripts, 
have not been tampered with.) 
The requester retrieves the instructions in the compatibility- 
checking script and follows them. If the software is not 
compatible with the repository, the installation transaction 
ends with an error. (This step checks platform 
20 compatibility.) 

The requester retrieves the instructions in the installation 
script and follows them. If there is an error in this process 
(such as insufficient resources), then the transaction ends 
with an error. Note that the installation process puts the 
25 runnable software in a place in the repository where it is 
no longer accessible as a work for exercising any usage 
rights other than the execution of the software as part of 
repository operations in carrying out other transactions. 
The repositories perform the common closing transaction 
30 steps. 

The Uninstall Transaction 

An Uninstall transaction is a request to remove software 
from a repository. Since uncontrolled or incorrect removal of 
35 software from a repository could compromise its behavioral 
integrity, this step is controlled. 

The requester sends the server an Uninstall message. This 
message indicates the work to be uninstalled, the version 
of the Uninstall right being invoked, and the file data for 
the work (including its size). 

The repositories perform the common opening transaction 
steps. 

The requester extracts a copy of the digital certificate for the 
45 software. If the certificate cannot be found or the master 
repository for the certificate is not known to the requester, 
the transaction ends with an error. 
The requester checks whether the software is installed. If the 
software is not installed, the transaction ends with an 
50 error. 

The requester decrypts the digital certificate using the public 
key of the master repository, recording the identity of the 
supplier and creator, a key for decrypting the software, the 
compatibility information, and a tamper-checking code. 

55 (This step authenticates the certification of the software, 
including the script for uninstalling it.) 
The requester decrypts the software using the key from the 
certificate and computes a check code on it using a 1-way 
hash function. If the check-code does not match the 

60 tamper-checking code from the certificate, the installation 
transaction ends with an error. (This step assures that the 
contents of the software, including the various scripts, 
have not been tampered with.) 
The requester retrieves the instructions in the uninstallation 

65 script and follows them. If there is an error in this process 
(such as insufficient resources), then the transaction ends 
with an error. 
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The repositories perform the common closing transaction 
steps. 

Distribution and Use Scenarios 

To appreciate the robustness and flexibility of the present 
invention, various distribution and use scenarios for digital 
works axe illustrated below. These scenarios are meant to be 
exemplary rather than exhaustive. 
Consumers as Unpaid Distributors 

In this scenario, a creator distributes copies of his works 
to various consumers. Each consumer is a potential distribu- 
tor of the work. If the consumer copies the digital work 
(usually for a third party), a fee is collected and automati- 
cally paid to the creator. 

This scenario is a new twist for digital works. It depends 
on the idea that "manufacturing" is just copying and is 
essentially free. It also assumes that the consumers as 
distributors do not require a fee for their time and effort in 
distributing the work. 

This scenario is performed as follows: 

A creator creates a digital work. He grants a Copy right 
with fees paid back to himself. If he does not grant an Embed 
right, then consumers cannot use the mechanism to act as 
distributors to cause fees to be paid to themselves on future 
copies. Of course, they could negotiate side deals or trades 
to transfer money on their own, outside of the system. 
Paid Distributors 

In another scenario, every time a copy of a digital work 
is sold a fee is paid to the creator and also to the immediate 
distributor. 

This scenario does not give special status to any particular 
distributor. Anyone who sells a document has the right to 
add a fee to the sale price. The fee for sale could be 
established by the consumer. It could also be a fixed nominal 
amount that is contributed to the account of some charity. 

This scenario is performed as follows: 

A creator creates a digital work. He grants a Copy right 
with fees to be paid back to himself. He grants an Embed 
right, so that anyone can add shells to have fees paid to 
themselves. 

A distributor embeds the work in a shell, with fees 
specified to be paid back to himself. If the distributor is 
content to receive fees only for copies that he sells himself, 
he grants an Extract right on the shell. 

When a consumer buys a copy from the distributor, fees 
are paid both to the distributor and to the creator. If he 
chooses, the consumer can extract the work from the dis- 
tributor's shell. He cannot extract it from the creator's shell. 
He can add his own shell with fees to be paid to himself. 
Licensed Distribution 

In this scenario, a creator wants to protect the reputation and 
value of his work by making certain requirements on its 
distributors. He issues licenses to distributors that satisfy 
the requirements, and in turn, promises to reward their 
efforts by assuring that the work will not be distributed 
over competing channels. The distributors incur expenses 
for selecting the digital work, explaining it to buyers, 
promoting its sale, and possibly for the license itself. The 
distributor obtains the right to enclose the digital work in 
a shell, whose function is to permit the attachment of 
usage fees to be paid to the distributor in addition to the 
fees to be paid to the creator. 

This differs from the previous scenario in that it precludes 
the typical copy owner from functioning as a distributor, 
since the consumer lacks a license to copy the document. 
Thus, a consumer cannot make copies, even for free. All 
copies must come initially from authorized distributors. This 
version makes it possible to hold distributors accountable in 
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some way for the sales and support of the work, by con- 
trolling the distribution of certificates that enable distributors 
to legitimately charge fees and copy owners to make copies. 
Since licenses are themselves digital works, the same 
5 mechanisms give the creators control over distributors by 
charging for licenses and putting time limits on their valid- 
ity. 

This scenario is performed as follows: 

A creator purchases a digital distribution license that he 
will hand out to his distributors. He puts access requirements 
(such as a personal license) on the Copy and Transfer rights 
on the distribution license so that only he can copy or 
transfer it. 

The creator also creates a digital work. He grants an 
Embed right and a Copy right, both of which require the 

35 distribution license to be exercised. He grants a Play right so 
that the work can be played by anyone. He may optionally 
add a Transfer or Loan right, so that end consumers can do 
some non-commercial exchange of the work among friends. 
A distributor obtains the distribution license and a number 

20 of copies of the work. He makes copies for his customers, 
using his distribution license. 

A customer buys and uses the work. He cannot make new 
copies because he lacks a distribution license. 
Super Distributors 

25 This is a variation on the previous scenarios. A distributor 
can sell to anyone and anyone can sell additional copies, 
resulting in fees being paid back to the creator. However, 
only licensed distributors can add fees to be paid to them- 
selves. 

3Q This scenario gives distributors the right to add fees to 
cover their own advertising and promotional costs, without 
making them be the sole suppliers. Their customers can also 
make copies, thus broadening the channel without dimin- 
ishing their revenues. This is because distributors collect 
fees from copies of any copies that they originally sold. Only 

35 distributors can add fees. 

This scenario is performed similarly to the previous ones. 
There are two key differences. (1) The creator only grants 
Embed rights for people who have a Distribution license. 
This is done by putting a requirement for a distributor's 

40 license on the Embed right. Consequently, non-distributors 
cannot add their own fees. (2) The Distributor does not grant 
Extract rights, so that consumers cannot avoid paying fees to 
the Distributor if they make subsequent copies. 
Consequently, all subsequent copies result in fees paid to the 

45 Distributor and the Creator. 
1 -Level Distribution Fees 

In this scenario, a distributor gets a fee for any copy he 
sells directly. However, if one of his customers sells further 
copies, he gets no further fee for those copies. 

50 This scenario pays a distributor only for use of copies that 
he actually sold. 

This scenario is performed similarly to the previous ones. 
The key feature is that the distributor creates a shell which 
specifies fees to be paid to him. He puts Extract rights on the 

55 shell. When a consumer buys the work, he can extract away 
the distributor's shell. Copies made after that will not require 
fees to be paid to the distributor. 
Distribution Trees 
In another scenario, distributors sell to other distributors 

60 and fees are collected at each level. Every copy sold by any 
distributor— even several d -blocks down in the chain — 
results in a fee being paid back to all of the previous 
distributors. 

This scenario is like a chain letter or value chain. Every 
65 contributor or distributor along the way obtains fees, and is 
thereby encouraged to promote the sale of copies of the 
digital work. 
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This scenario is performed similarly to the previous ones. 
The key feature is that the distributor creates a shell which 
specifies fees to be paid to him. He does not grant Extract 
rights on the shell. Consequently, all future copies that are 
made will result in fees paid to him. 
Weighted Distribution Trees 

In this scenario, distributors make money according to a 
distribution tree. The fee that they make depends on various 
parameters, such as time since their sale or the number of 
subsequent distributors. 

This is a generalized version of the Distribution Tree 
scenario, in that it tries to vary the fee to account for the 
significance of the role of the distributor. 

This scenario is similar to the previous one. The differ- 
ence is that the fee specification on the distributor's shell has 
provisions for changes in prices. For example, there could be 
a fee schedule so that copies made after the passage of time 
will require lower fees to be paid to the distributor. 
Alternatively, the distributor could employ a "best-price" 
billing option, using any algorithm he chooses to determine 
the fee up to the maximum specified in the shell. 
Fees for Reuse 

In this scenario, a first creator creates a work. It is 
distributed by a first distributor and purchased by a second 
creator. The second creator extracts a portion of the work 
and embeds in it a new work distributed by a second 
distributor. A consumer buys the new work from the second 
distributor. The first creator receives fees from every trans- 
action; the first distributor receives fees only for his sale; the 
second creator and second distributor receive fees for the 
final sale. 

This scenario shows how that flexible automatic arrange- 
ments can be set up to create automatic charging systems 
that mirror current practice. This scenario is analogous to 
when an author pays a fee to reuse a figure in some paper. 
In the most common case, a fee is paid to the creator or 
publisher, but not to the bookstore that sold the book. 

The mechanisms for derived works are the same as those 
for distribution. 
Limited Reuse 

In this scenario, several first creators create works. A 
second creator makes a selection of these, publishing a 
collection made up of the parts together with some new 
interstitial material. (For example, the digital work could be 
a selection of music or a selection of readings.) The second 
creator wants to continue to allow some of the selected 
works to be extractable, but not the interstitial material. 

This scenario deals with fine grained control of the rights 
and fees for reuse. 

This scenario is performed as follows: 

The first creators create their original works. If they grant 
extraction and embedding rights, then the second creator can 
include them in a larger collected work. The second creator 
creates the interstitial material. He does grant an Extract 
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Demo Versions 

A creator believes that if people try his work that they will 
want to buy it or use it. Consumers of bis work can copy the 
work for free, and play (or execute) a limited version of the 
5 work for free, and can play or use the full featured version 
for a fee. 

This scenario is performed as follows: 
The creator creates a digital work and grants various 
rights and fees. The creator grants Copy and Embed rights 
10 without a fee, in order to ensure widespread distribution of 
the work. Another of the rights is a limited play right with 
little or no fee attached. For example, this right may be for 
playing only a portion of the work. The play right can have 
various restrictions on its use. It could have a ticket that 
limits the number of times it is used. It could have internal 
restrictions that limit its functionality. It could have time 
restrictions that invalidate the right after a period of time or 
a period of use. Different fees could be associated with other 
versions of the Play right. 
Upgrading a Digital Work with a Vendor 

A consumer buys a digital work together with an agree- 
ment that he can upgrade to a new version at a later date for 
a modest fee, much less than the usual purchase price. When 
the new version becomes available, he goes to a qualified 
vendor to make the transaction. 

This scenario deals with a common situation in computer 
software. It shows how a purchase may include future 
"rights." Two important features of the scenario are that the 
transaction must take place at a qualified vendor, and that the 
transaction can be done only once per copy of the digital 
work purchased. 
This scenario is performed as follows: 
The creator creates a digital work, an upgrade ticket, and 
a distribution license. The upgrade ticket uses the a generic 
ticket agent that comes with repositories. As usual, the 
distribution license does not have Copy or Transfer rights. 
He distributes a bundled copies of the work and the ticket to 
his distributors as well as distribution licenses. 

The distributor sells the old bundled work and ticket to 
40 customers. 

The customer extracts the work and the ticket. He uses the 
work according to the agreements until the new version 
becomes available. 

When the new work is ready, the creator gives it to 
distributors. The new work has a free right to copy from a 
distributor if a ticket is available. 

The consumer goes to distributors and arranges to copy 
the work. The transaction offers the ticket. The distributor's 
repository punches the ticket and copies the new version to 
the consumers repository. 

The consumer can now use the new version of the work. 
Distributed Upgrading of Digital Works 

A consumer buys a digital work together with an agree- 
ment that he can upgrade to a new version at a later date for 
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right on the interstitial material. He grants Extract rights on 55 a modest fee, much less than the usual purchase price. When 



a subset of the reused material. A consumer of the collection 
can only extract portions that have that right. Fees are 
automatically collected for all parts of the collection. 
Commercial Libraries 

Commercial libraries buy works with the right to loan. 
They limit the loan period and charge their own fees for use. 
This scenario deals with fees for loaning rather than fees for 
making copies. The fees are collected by the same automatic 
mechanisms. 

The mechanisms are the same as previous scenarios 
except that the fees are associated with the Loan usage right 
rather than the Copy usage right. 
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the new version becomes available, he goes to anyone who 
has the upgraded version and makes the transaction. 

This scenario is like the previous one in that the transac- 
tion can only be done once per copy of the digital work 
purchased, but the transaction can be accomplished without 
the need to connect to a licensed vendor. 

This scenario is similar to the previous one except that the 
Copy right on the new work does not require a distribution 
license. The consumer can upgrade from any repository 
having the new version. He cannot upgrade more than once 
because the ticket cannot work after it has been punched. If 
desired, the repository can record the upgrade transaction by 
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posting a zero cost bill to alert the creator that the upgrade 
has taken place. 
Limited Printing 

A consumer buys a digital work and wants to make a few 
ephemeral copies. For example, he may want to print out a 5 
paper copy of part of a digital newspaper, or he may want to 
make a (first generation) analog cassette tape for playing in 
bis car. He buys the digital work together with a ticket 
required for printing rights. 

This scenario is like the common practice of people 10 
making cassette tapes to play in their car. If a publisher 
permits the making of cassette tapes, there is nothing to 
prevent a consumer from further copying the tapes. 
However, since the tapes are "analog copies," there is a 
noticeable quality Loss with subsequent generations. The 15 
new contribution of the present invention is the use of tickets 
in the access controls for the making of the analog copies. 

This scenario is performed as follows: 

The creator sells a work together with limited printing 
rights. The printing rights specify the kind of printer (e.g., a 20 
kind of cassette recorder or a kind of desktop paper printer) 
and also the kind of ticket required. The creator either 
bundles a limited number of tickets or sells them separately. 
If the tickets use the generic ticket agent, the consumer with 
the tickets can exercise the right at his convenience. 25 
Demand Publishing 

Professors in a business school want to put together 
course books of readings selected from scenario studies 
from various sources. Hie bookstore wants to be able to print 
the books from digital masters, without negotiating for and 30 
waiting for approval of printing of each of the scenarios. The 
copyright holders of the scenarios want to be sure that they 
are paid for every copy of their work that is printed. 

On many college campuses, the hassle of obtaining copy 
clearances in a timely way has greatly reduced the viability 35 
of preparing course books. Print shops have become much 
more cautious about copying works in the absence of 
documented permission. 

Demand Publishing is performed as follows: the creator 
sells a work together with printing rights for a fee. There can 40 
be rights to copy (distribute) the work between bookstore 
repositories, with or without fee. The printing rights specify 
the kind of printer. Whenever a bookstore prints one of the 
works (either standalone or embedded in a collection), the 
fee is credited to the creator automatically. To discourage 45 
unauthorized copying of the print outs, it would be possible 
for the printer to print tracer messages discretely on the 
pages identifying the printing transaction, the copy number, 
and any other identifying information. The tracer informa- 
tion could be secretly embedded in the text itself (encoded 50 
in the grey scale) or hidden in some other way. 
Metered Use and Multiple Price Packages 

A consumer does not know what music to purchase until 
he decides whether he likes it. He would like to be able to 
take it home and listen to it, and then decide whether to 55 
purchase. Furthermore, he would like the flexibility of 
paying less if he listens to it very infrequently. 

This scenario just uses the capability of the approach to 
have multiple versions of a right on a digital work. Each 
version of the right has its own billing scheme. In this 60 
scenario, the creator of the work can offer the Copy right 
without fee, and defer billing to the exercise of the Play 
right. One version of the play right would allow a limited 
performance without fee — a right to "demo". Another ver- 
sion of the right could have a metered rate, of say $0.25 per 65 
hour of play. Another version could have a fee of S15.00 for 
the first play, but no fee for further playing. When the 
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consumer exercises a play right, he specifies which version 
of the right is being selected and is billed accordingly. 
Fees for Font Usage 

A designer of type fonts invests several months in the 
design of special fonts. The most common way of obtaining 
revenue for this work is to sell copies of the fonts to 
publishers for unlimited use over unlimited periods of time. 
A font designer would like to charge a rate that reflects the 
amount that the font is used. 

This scenario is performed as follows: the font designer 
creates a font as a digital work. He creates versions of the 
Play right that bill either for metered use or "per-use". Each 
version of the play right would require that the player (a 
print layout program) be of an approved category. The font 
designer assigns appropriate fees to exercise the Copy right. 
When a publisher client wants to use a font, he includes it 
as input to a layout program, and is billed automatically for 
its use. In this way, a publisher who makes little use of a font 
pays less than one who uses it a lot. 
Rational Database Usage Charges 

Online information retrieval services typically charge for 
access in a way that most clients find unpredictable and 
uncorrelated to value or information use. The fee depends on 
which databases are open, dial-up connect time, how long 
the searches require, and which articles are printed out. 
There are no provisions for extracting articles or 
photographs, no method for paying to reuse information in 
new works, no distinction between having the terminal sit 
idly versus actively searching for data, no distinction 
between reading articles on the screen and doing nothing, 
and higher rates per search when the centralized facility is 
busy and slow servicing other clients. Articles can not be 
offloaded to the client's machine for off-site search and 
printing. To offer such billing or the expanded services, the 
service company would need a secure way to account for 
and bill for how information is used. 

This scenario is performed as follows; 

The information service bundles its database as files in a 
repository. The information services company assigns dif- 
ferent fees for different rights on the information files. For 
example, there could be a fee for copying a search database 
or a source file and a different fee for printing. These fees 
would be in addition to fees assigned by the original creator 
for the services. The fees for using information would be 
different for using them on the information service compa- 
ny's computers or the client's computers. This billing dis- 
tinction would be controlled by having different versions of 
the rights, where the version for use on the service compa- 
ny's computer requires a digital certificate held locally. Fees 
for copying or printing files would be handled in the usual 
way, by assigning fees to exercising those rights. The 
distinction between searching and viewing information 
would be made by having different "players" for the differ- 
ent functions. This distinction would be maintained on the 
client's computers as well as the service computers. Articles 
could be extracted for reuse under the control of Extract and 
Embed rights. Thus, if a client extracts part of an article or 
photograph, and then sells copies of a new digital work 
incorporating it, fees could automatically be collected both 
by the information service and earlier creators and distribu- 
tors of the digital work. In this way, the information retrieval 
service could both offer a wider selection of services and 
billing that more accurately reflects the client's use of the 
information. 

Print Spooling with Rights 

In the simplest scenario, when a user wants to print a 
digital document he issues a print command to the user 
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interface. If the document has the appropriate rights and the Content 

conditions are satisfied, the user agrees to the fee and the The digital information (i.e. raw bits) representing a 

document is printed. In other cases, the printer may be on a digital work, 

remote repository and it is convenient to spool the printing Copy Owner 

to a later time. This leads to several issues. The user 5 A term which refers to the party who owns a digital work 

requesting the printing wants to be sure that he is not billed stored in a repository. In the typical case, this party has 

for the printing until the document is actually printed purchased various ^ lo the document for printing, 

Restated, if he is bdled at the time the prmt job is spooled vkwin transferringf or other ific ^ 

but the job is canceled before printing is done, he does not Creator 

want to pay. Another issue is that when spooling is „ A . . f . , . , 

... A V J . .. . . . *\ j- 10 A te nn which refers to a party who produces a digital 

permitted, there are now two times at which rights, condi- ^ r j r &* 

tions and fees could be checked: the time at which a print job Credit Server 

is spooled and the time at which a print is made. As with all A . , 4 . ..... . r 

• . -U1 * i. ■ u* *u * • a . A device which collects and reports billing information 

usage rights, it is possible to have rights that expire and to c ¥ , « ... 

. 6 • r ' , V j a - i ... . for a repository. In many implementations, this could be 

have rights whose fee depends on various conditions. What „ . r . c 3 T * ■ e • j- 

. . * . . j j ,. A . , iL 15 built as part oi a repository. It requires a means for penodi- 

is needed is a means to check rights and conditions at the „ * m „„i„ ati ll ™tu , w;ii-L ^i« B „ n „u™„ n 
, . • it j cally communicating witn a billing clearinghouse, 

time that printing is actually done. r* • t 

rr.. .._r j #. ii . . . . Description Tree 

lnis scenano is performed as follows: A printing reposi- * . l-^j . . - i4 . 

- t u *u i •* u . A structure which describes the location of content and 

tory is a repository with the usual repository characteristics ... , c e .„ , 

. . . j, j a * *T, . „ the usage rights and usage fees for a digital work. A 

plus the hardware and software to enable printing. Suppose _ , • ■ . - . e , r , . . & . . . „ . 

f, t . . t . . t j T . i 20 description tree is comprised of description blocks. Each 

that a user logs mto a home repository and wants to spool A • . , , , . ,. , , 

. . . , c °^ ,. ... . . ; . descnption block corresponds to a digital work or to an 

print jobs for a digital work at a remote printing repository. n . • * A • , 

ir, J . . - ^ ... ,j , , ,f. . / interest (typically a revenue bearing interest) in a digital 

The user interface for this could treat this as a request to v,r J 6 ' ^ 

"spool" prints. Underneath this "spooling" request, Diaital Work (Work} 

however, are standard rights and requests. To support such „„ A \ . , .„ , . c . „ , . . - 

requests, the creator of the work provides a Copy right, 25 enca P sulated ^ information. Such digital mfor- 

which can be used to copy the work to a printing repository m ^ on may K * K ™ 1 m ™ 1C > a . " a S a ™ or book ; o ; * 
, , f u f' ... u u r multimedia composition. Usage rights and fees are attached 

In the default case, this Copy right would have no fees . .... **. 5 

associated for making the copy. However, the Next-Set-Of- Distrmutor 

Rights for the copy would only include the Print rights, with „„ A# .. . c . , • t . . 

.u ir c u - .- r • rr,. . c 30 A term which refers to a party who legitimately obtains a 
the usual fees for each variation of printing. This version of f ^ . . . &n / oS * it for s ale y 

the Copy right could be called the "print spooling" version f° Py ^ g1 ^. * D ^° , 11 t0f Sale< 

ofthe Spy right. The user's "spool request" is implemented Identification (Digital) Certuicate 

as a Copy ^nsaction to put a copy of the work on the A signedldigital message that attests to the idenUtyof he 

printing repository, followed by Print transactions to create „ SZt^ J^T ^1 ^ cemfi f cates are f encr yP ted m the 

me prints of :he work. In this way, the user is only billed for 35 P nV f ^ ° f , a wll * nown maSter re P OSltor y- 

printing that is actuaUy done. Furthermore, the rights, con- Master Repository 

ditions and fees for prmting the work are determined when ^ ^ ? U6S lde u ntlfica ^ on 

the work is about to be printed. certificates and distributes lists of repositories whose integ- 

tu.. c „ c„ct»«, *«f„ m „„ ,u. ■ t t t , nty have been compromised and which should be denied 

are preferred, it will be appreciated from this teaching that A ! y .■ Cr ^P . • • 

i. ,■ ■ An encrypUon technique used for secure transmission of 

vanous alternative, modifications, variations or improve- ,r 7 . . « 

ments therein may be made by those skilled in the art, which meS f ag6S OD • ^ hann f ^ pairs are used 

are intended to be encompassed by the following claims. M for ^ e encr yP Uo ° ^J?" ° f me ^f S ' ^ ca ^ y 
r J & 45 one key is referred to as the public key and the other is the 

GLOSSARY private key. The keys are inverses of each other from the 

Authorization Repository perspective of encryption. Restated, a digital work that is 

A special type of repository which provides an authori- encrypted by one key in the pair can be decrypted only by 

zation service. An authorization may be specified by a usage the other. 

right. The authorization must be obtained before the right 50 Registration Transactions 

may be exercised. The protocol used between repositories to establish a 

Billing Clearinghouse trusted session. 

A financial institution or the like whose purpose is to Rendering Repository 

reconcile billing information received from credit servers. A special type of repository which is typically coupled to 

The billing clearinghouse may generate bills to users or 55 a rendering system. The rendering repository will typically 

alternatively, credit and debit accounts involved in the be embodied within the secure boundaries of a rendering 

commercial transactions. system. 

Billing Transactions Rendering System 

The protocol used by which a repository reports billing The combination of a rendering repository and a render- 
information to a credit server. 60 ing device. Examples of a rendering systems include print- 
Clearinghouse Transactions ing systems, display systems, general purpose computer 

The protocol used between a credit server and a clear- systems, video systems or audio systems, 

inghouse. Repository 

Composite Digital Work Conceptually a set of functional specifications defining 

Adigital work comprised of distinguishable parts. Each of 65 core functionality in the support of usage rights. Arepository 

the distinguishable parts is itself a digital work which have is a trusted system in that it maintains physical, communi- 

have usage rights attached. cations and behavioral integrity. 
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Requester Mode 

A mode of a repository where it is requesting access to a 
digital work. 
Revenue Owners 

A term which refers to the parties that maintain an interest 
in collecting fees for document use or who stand to lose 
revenue if illegitimate copies of the digital work are made. 
Server Mode 

A mode of a repository where it is processing an incoming 
request to access a digital work. 
Shell Description Block 

A special type of description block designating an interest 
in a digital work, but which does not add content. This will 
typically be added by a distributor of a digital work to add 
their fees. 
Transactions 

A term used to refer to the protocols by which repositories 
communicate. 
Usage Fees 

A fee charged to a requester for access to a digital work. 
Usage fees are specified within the usage rights language. 
Usage Rights 

A language for defining the manner in which a digital 
work may be used or distributed, as well as any conditions 
on which use or distribution is premised. 
Usage Transactions 

A set of protocols by which repositories communicate in 
the exercise of a usage rights. Each usage right has it's own 
transaction steps. 

What is claimed: 

1. A method for controlling access to digital works in a 
network of computer based systems comprising the steps of: 

a) for a digital work requiring controlled access, attaching 
a plurality of usage rights to said digital work; 

b) for an associated one of said attached plurality of usage 
rights, specifying that a digital ticket must be possessed 
by a requesting repository as a condition for perfor- 
mance of said corresponding usage right to be granted; 

c) storing said digital work and attached usage rights in a 
first repository; 

d) creating and storing said digital ticket in a second 
repository, said digital ticket itself being an instance of 
a digital work; 

e) a third repository obtaining a copy of said digital ticket 45 
from said second repository; 

f) said third repository transmitting a request to access 
said digital work to said first repository, said request for 
access specifying said associated one of said plurality 
of usage rights that specifies said digital ticket; 

g) said first repository querying said third repository for 
said digital ticket; 

h) said third repository confirming possession of said 
digital ticket to said first repository; and 

i) said first repository validating said third repository 
possesses said digital ticket and transmitting said digi- 
tal work to said third repository. 

2. The method as recited in claim 1 further comprising the 
step of: 

j) said first repository punching said digital ticket to 
indicate access by said third repository. 

3. The method as recited as in claim 1 further comprising 
the step of said third repository copying said digital ticket 
from said second repository for a fee. 

4. The method as recited in claim 3 wherein said digital 
ticket is comprised of a first timestamp part for storing a time 



when said digital ticket was copied and a second timestamp 
part for storing a timestamp when said digital ticket was 
punched and said step of copying said digital ticket from 
said second repository for a fee is further comprised of the 
5 step of said second repository marking said first timestamp 
part of said digital ticket with a copy timestamp indicating 
the time and date the copy of said digital ticket was made. 

5. The method as recited in claim 4 further comprising the 
step of said first repository marking said second timestamp 

10 part of said digital ticket with a punch timestamp indicating 
the time and date the digital ticket was punched. 

6. The method as recited in claim 5 wherein said method 
is further comprised of the step of said third repository 
refreshing said digital ticket to enable a subsequent reuse. 

7. The method as recited in claim 6 therein said step of 
said third repository refreshing said digital ticket to enable 
a subsequent reuse is further comprised of the steps of: 

k) said third repository making a copy of said digital ticket 
for a fee: and 

1) said third repository marking said first timestamp part 
of said digital ticket with a copy timestamp indicating 
the time and date the digital ticket was refreshed. 

8. In a computer controlled system for the distribution of 
digital works, a method for controlling the access to said 
digital works, said method comprising the steps of: 

a) creating a digital work and a digital ticket, said digital 
ticket being an instance of a digital work; 

b) defining a plurality of usage rights for said digital work, 
wherein a first of said usage rights specifies said digital 
ticket and a special ticket agent for punching said 
digital ticket; 

c) storing said digital work in a first repository; 

d) distributing said digital ticket to a second repository; 

e) said second repository transmitting a request to access 
said digital work to said first repository, said request 
specifying said first usage right; 

f) said first repository determining if said second reposi- 
tory has said digital ticket; 

g) said second repository presenting said digital ticket to , 
said first repository; 

h) said first repository presenting said digital ticket to said 
special ticket agent; 

i) said special ticket agent determining if said digital 
ticket is valid; 

j) if said digital ticket is invalid, said special ticket agent 

causing said request to access to be denied; 
k) if said digital ticket is valid, said special ticket agent 

punching said digital ticket; and 
1) said first repository granting access to said digital work 
by said second repository. 

9. In a computer controlled system for the distribution of 
digital works, a method for distribution of upgrades to said 
digital works, said method comprising the steps of: 

a) creating a digital ticket, said digital ticket for permitting 
copying of an upgrade digital work, said digital ticket 
being an instance of a digital work; 

b) distributing said digital ticket and a corresponding 
digital work to a first repository for a fee; 

c) creating said upgrade digital work, said upgrade digital 
work having a copying right for permitting copying of 
said upgrade digital work to possessors of said digital 
ticket; 

d) storing said upgrade digital work in a second reposi- 
tory; 
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e) said first repository transmitting a request to copy said 
upgrade digital work to said second repository; 

f) said second repository determining if said first reposi- 
tory has said digital ticket; 

g) said first repository presenting said digital ticket to said 5 
second repository; 

h) said second repository determining if said digital ticket 
is valid; 
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i) if said digital ticket is invalid, said second repository 
causing said request to copy to be denied; 

j) if said digital ticket is valid, said second repository 
punching said digital ticket; and 

k) said second repository transmitting said upgrade digital 
work requested by said first repository. 
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